Fantastic: because that's what it does!
Clint Webb wrote:
To elaborate my take on the above scenario, I would expect that client A
would get 2, and client B would get 3. The final result in memcached
would be 3 if anyone else does a 'get' afterwards. I would certainly
NOT expect two clients to ever receive the same number from an incr. In
fact, if it ever did, that would break quite a number of my processes
actually.
On Tue, Feb 26, 2008 at 11:38 AM, dormando <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Steve Chu wrote:
> I'm sorry that my expression may confuse you. I try to make it
more clear.
> My requirement is that clients to incr/decr a value must be atomic,
> that get from slabber and
> add 1 must be an atomic operation according to clients(php clients or
> libmemcached etc.). If two clients incr a value 1, the value should
> be 3, not that B client overwrite the value, and the final value is
> still 2. This operation in Non-thread is atmoic, because they are not
> in concurrent environment, and only one event is processed one time.
>
> But now I found in multithread version it is not atomic, if put the
> item_get in add_delta, this may be done, but too many locks.
>
> I wonder if you understand my meaning, anyway,
>
I understand your meaning. It is actually atomic, if two threads hit
that code at the same time, the final value will be 3, it will not
be two.
The value in the slabber is updated *inside* of add_delta, so there's no
way it could end up being 2 if two threads incr it from 1.
-Dormando
--
"Be excellent to each other"
