Re: [APC-DEV] atomaticity/thread safeness of apc shared memory functions+mutexes

From: Date: Thu, 25 Dec 2008 17:55:41 +0000
Subject: Re: [APC-DEV] atomaticity/thread safeness of apc shared memory functions+mutexes
References: 1 2 3 4 5 6 7 8  Groups: php.apc.dev 
Request: Send a blank email to php-apc-dev+get-181@lists.php.net to get a copy of this message
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.

« previous php.apc.dev (#181) next »