Re: [APC-DEV] atomaticity/thread safeness of apc shared memory functions+mutexes
[email protected] (Exception e) Thu, 25 Dec 2008 18:55:41 +0100
| Newsgroups | php.apc.dev |
|---|---|
| Message-ID | <[email protected]> |
Rasmus Lerdorf schreef:
>> function lock($entry) {
>> // busy wait
>> while(!apc_add($entry.'.lock'))
>> sleep(1);
>> }
>>
>> function unlock($entry) {
>> return apc_delete($entry.'.lock');
>> }
>>
>> lock('obj1');
>> lock('obj2');
>> $obj1= apc_fetch('obj1');
>> $obj2 = apc_fetch('obj2');
>>
>> //process, apc_store val1 and val2 again
>>
>> unlock('obj1');
>> unlock('obj2');
>>
>>
>> Then it would only be nice if lock and unlock would be part of apc_*
>> userland functions. I am curious about your ideas.
>
> You could do something like that, but it would be amazingly inefficient.
Because of the busy wait or is access to shared memory slow?
> and can't possibly scale to multiple machines behind a load balancer.
I also think that a load balancer will harm you. Then you need something
like memcache. For this experimentation I don't need to bother about this.
> Also, storing objects in shared memory is slow and usually pointless.
> Only the properties of the object are stored anyway, so you may as well
> store an array directly. That has the benefit of not needing serialization.
Yes, but I initially thought that the only alternative (database with
lockings) would be way slower. If this is not the case I would happily
abandon apc. My assumption was that shared memory access would be
blazingly fast.