[Mono-devel-list] RE: [Gc] [PATCH] Race condition when restarting threads

[Boehm, Hans]

I still don't think I understand the scenario.

The original thread in (1) was suspended from the last GC?

My assumption is that if thread A sends a signal to thread B, then
Bs handler sees all memory operations performed by A before the
signal was sent.  I don't think that's officially guaranteed, but I
would be amazed if it weren't true everywhere.

Thus in step (2) if the thread wakes up after the suspend signal has
been
sent, it must see both the updates to GC_stop_count and
GC_world_stopped.
(And it was suspended from the preceding round, the new suspend signal
should still be pending anyway, I think.)
If it wakes up before, it will get another signal telling it to stop.
What am I missing?

Hans

> -----Original Message-----
> From: Ben Maurer [mailto:bmaurer at ximian.com] 
> Sent: Monday, August 01, 2005 4:24 PM
> To: Boehm, Hans
> Cc: gc at napali.hpl.hp.com; mono-devel-list at lists.ximian.com
> Subject: RE: [Gc] [PATCH] Race condition when restarting threads
> 
> 
> On Mon, 2005-08-01 at 15:09 -0700, Boehm, Hans wrote:
> > I don't quite understand the problem here.  If 
> GC_stop_count has just 
> > been incremented, then I'm about to send another suspend 
> signal to the 
> > thread, and it will have to stop again before we think the world is 
> > stopped.
> 
> My situation is:
> 
> 1) the thread suspending other threads has done both 
> GC_stop_count ++ and GC_world_is_stopped = TRUE
> 2) A suspended thread wakes up from sigsuspend (on a random signal)
> 3) By the time it wakes up, the GC_stop_count has taken 
> effect (as seen by this thread), but GC_world_is_stopped has not
> 4) The thread thus thinks that the world is being started up 
> again and continues.
> 
> -- Ben
> 
>