Re: recursive spinlocks. Shoot.

[Davide Libenzi <davidel@xmailserver.org>]

On Mon, 19 May 2003, Peter T. Breuer wrote:

> "A month of sundays ago Davide Libenzi wrote:"
> > On Mon, 19 May 2003, Peter T. Breuer wrote:
> >
> > > No. This is not true. Imagine two threads, timed as follows ...
> > >
> > >     .
> > >     .
> > >     .
> > >     .
> > > if ((snl)->uniq == current) {
> > > atomic_inc(&(snl)->count); 		.
> > > } else { 				.
> > > spin_lock(&(snl)->lock);		.
> > > atomic_inc(&(snl)->count);		.
> > > (snl)->uniq = current; 	  <->	if ((snl)->uniq == current) {
> > > 				atomic_inc(&(snl)->count);
> > > 				} else {
> > > 				spin_lock(&(snl)->lock);
> > > 				atomic_inc(&(snl)->count);
> > > 				(snl)->uniq = current;
> > >
> > >
> > > There you are. One hits the read exactly at the time the other does a
> > > write. Bang.
> >
> > So, what's bang for you ? The second task (the one that reads "uniq")
> > will either see "uniq" as NULL or as (task1)->current. And it'll go
> > acquiring the lock, as expected. Check it again ...
>
> Perhaps I should expand on my earlier answer ...
>
> (1) while, with some luck, writing may be atomic on ia32 (and I'm not
> sure it is, I'm only prepared to guarantee it for the lower bits, and I
> really don't know about zeroing the carry and so on), I actually doubt
> that reading is atomic, or we wouldn't need the atomic_read
> construction!

Look at atomic read :

$ emacs `find /usr/src/linux/include -name atomic.h | xargs`


> (3) even if one gets either one or the other answer, one of them would
> be the wrong answer, and you clearly intend the atomic_inc of the
> counter to be done in the same atomic region as the setting to current,
> which would be a programming hypothesis that is broken when the wrong
> answer comes up.

Atomic inc/dec/add/sub are different to read/write an aligned sizeof(int)
memory location. An aligned sizeof(int) read/write must be atomic for the
bare bone CPU memory coherency. While add/sub/add/inc are (or at least can
be) split in MEMOP(load)->ALUOP(?)->MEMOP(store) whose full cycle is not
guaranteed to be atomic, load/store of sizeof(int) aligned memory location
are not split is every CPU whose designer was not drunk during the
architectural phase. Or better, if they are split due some sort of HW
limitation, the HW itself has to guarentee the atomicity of the operation.
Intel tries also to guarantee the atomicity of non aligned load/store by
doing split locks on the memory bus. If you have :

int a;

thread1:
	for (;;)
		a = 1;

thread2:
	for (;;)
		a = -1;

being "a" an aligned memory location, a third thread reading "a" reads
either 1 or -1. Going back to the (doubtfully useful) code, you still have
to point out were it does bang ...



- Davide