if there are too many mutex calls these can become scalability
issues. Solaris 10 has some atomic routines that could be helpfull.
See http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/
common/sys/atomic.h
for the routines.
Of course if multiple operations are needed that need the protection
of a mutex than a atomic operation is no alternative, besides a CPU
consuming polling device. And sometimes these come in handy too.
--Paul
On 25-feb-2008, at 10:53, Steve Chu wrote:
On Mon, Feb 25, 2008 at 4:28 PM, dormando <[EMAIL PROTECTED]> wrote:
Steve Chu wrote:
On Mon, Feb 25, 2008 at 2:51 PM, dormando <[EMAIL PROTECTED]>
wrote:
I think this is fine?
Since the operations are independently atomic, it's perfectly
valid for
two threads to incr the same value.
But for client api, they seems NOT atomic, because when Thread A
just
has 'item_get' done but before 'add_delta', Thread B can still do
item_get.
X-> set "foo" 1
A-> item_get "foo"
B-> item_get "foo"
A-> add_delta "foo" by 1
B-> add_delta "foo" by 1
then A and B both hold value 2, which one should be stored?
And the exact value we need is 3, right? I am not quit sure, correct
me if i am wrong:)
The result gets copied into the thread-local 'temp' buffer, then
copied
into that connection (implicitly atomic)'s output buffer.
So actually I read the code wrong the first time. This _should_
do the
right thing:
We have threads (A, B, X):
X -> set 'foo' 1
A -> process_arithmetic_command()
note thread local storage (char temp[])
B -> same.
A -> it = item_get(key, nkey)
(atomically increments the refcount for that item, returns a
reference
to it)
B -> same, same time.
(same)
A -> out_string(c, add_delta(it, incr, delta, temp));
add_delta runs atomically, copies the result of the addition into
the
thread local 'temp' buffer and _returns the 'temp' buffer_ (which
contains 2)
B -> out_string(c, add_delta(it, incr, delta, temp));
Gets serialized behind A, and its 'temp' then holds a value one
higher
than A's (containing 3)
Here I am confused. Every thread has a local var 'temp' and here
'temp' should hold 2. 'temp' is independent, and doesn't share
between threads. So thread B should overwrite the value in the
slabber. Am I right?
A -> runs out_string(c, temp), with 'temp' having the atomically
incremented value.
A -> inside out_string, copy's the contents of the original 'temp'
buffer into the connection's local write buffer, then sets the
connection into write mode (which will flush its buffer before doing
further processing). Then returns.
A -> returns to the state machine, 'temp' goes to the wolves, etc.
A -> sends value '2' to its client.
B -> Same thing. Client should receive a '3'.
Apologies to the original patch author and the list for the
confusion :)
I had mentally confused "normal" responses and "get" responses,
which
operate differently.
-Dormando
It's possible that with two threads (A, B):
X -> set "foo" 1
A -> incr "foo" by 1
B -> incr "foo" by 1
A -> returns 3
B -> returns 3
The only guarantee the slabber makes for returning values, is
that they
won't get deleted before being transferred through the network.
Could be wrong, but that's my impression from checking the
sources.
-Dormando
Steve Chu wrote:
In 'process_arithmetic_command' function:
We first do item_get from slabs and then do add_delta to incr/
decr the value.
My question is:
Is this atomic in multithread mode? Item_get is atomic and so is
add_delta because they are protected by mutex. But the entire two
operations seems NOT atomic. Two threads can both do item_get with
same key, then both incr it, and write back.
Anybody can tell me whether it is a bug or not?
Regards,
Steve Chu
--
Steve Chu
http://stvchu.org
------------------------------------------------------------------------
---------------------
Paul van den Bogaard
[EMAIL PROTECTED]
ISV-E -- ISV Engineering, Opensource Engineering group
Sun Microsystems, Inc phone: +31
334 515 918
Saturnus 1
extentsion: x (70)15918
3824 ME Amersfoort mobile: +31
651 913 354
The Netherlands
fax: +31 334 515 001
