[Gc] [PATCH] Race condition when restarting threads

Ben Maurer bmaurer at ximian.com
Tue Jul 12 23:28:40 PDT 2005


On Tue, 2005-07-12 at 11:42 -0700, Boehm, Hans wrote:
> > Your patch had the fields set as volatile, so shouldn't the 
> > compiler ensure that the cpu does not reorder the stores?
> We had a long discussion of that on the C++ memory model list.
> The answer is architecture dependent.  Volatile will generally
> prevent compiler reordering.  It usually introduces the necessary
> hardware barriers on Itanium, but not, for example, on PowerPC.

I think your version has a race if this is the case:

> +    sigsuspend(&suspend_handler_mask);        /* Wait for signal */
> +    while (GC_world_is_stopped && GC_stop_count == my_stop_count) {

Imagine that this thread gets a spurious signal. The GC_stop_count++
statement has already taken effect, but the GC_world_is_stopped = TRUE
has not, the thread would bypass the wait, causing the world not to be
stopped.

In fact, how do we know that my_stop_count is correct?

When I put this in the mono tree, I'd really have something with
barriers in it and use the version that I suggested. Without the
barriers, am a bit worried about the correctness (especially since the
issues happen on platforms I am not testing with).

-- Ben



More information about the Gc mailing list