Subject: Re: x86 instructions reordering
To: TLorD <>
From: Manuel Bouyer <>
List: port-i386
Date: 03/25/2005 18:09:34
On Fri, Mar 25, 2005 at 12:22:13PM +0100, TLorD wrote:
> Hash: SHA1
> Drats, forgot about the did_something/goto thing.
> This makes the lock it a bit more unlikely, but still possible.
> (by the way, you DID set did_something = 0 after again:, didn't you?)


> What happens when
> did_something = 1, goto again, just passed the a = shared_memory->a; line
> send()
> Another handle_event is run (after all, send_event() is run)? If so, you 
> might
> have a race condition in which the first writes new_b = b + 1, then the 
> first
> one goes new_b = b and you're out of sync again.
> Is it ignored? then b falls behind a again.

Events are queued. So if send_event() is called while handle_event() is 
running, we won't have 2 threads running handle_event(), but handle_event()
will be called again when it exits. So what you describe here shouldn't
It is possible that the problem is in the way events are queued.
I already have debugged this part, but it's still possible I missed one bug.

Manuel Bouyer <>
     NetBSD: 26 ans d'experience feront toujours la difference