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.