Subject: Re: x86 instructions reordering
To: TLorD <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 03/25/2005 18:09:34
On Fri, Mar 25, 2005 at 12:22:13PM +0100, TLorD wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> Another handle_event is run (after all, send_event() is run)? If so, you
> have a race condition in which the first writes new_b = b + 1, then the
> 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 <firstname.lastname@example.org>
NetBSD: 26 ans d'experience feront toujours la difference