[Gc] [PATCH] Race condition when restarting threads

Ben Maurer bmaurer at ximian.com
Tue Jul 12 11:22:27 PDT 2005


On Tue, 2005-07-12 at 11:13 -0700, Boehm, Hans wrote:
> I think I generally also prefer your solution.
> 
> But it seems to me that it has a very low probability memory ordering
> issue.
> 
> If I see GC_world_is_stopped set because I'm trying to stop the
> world for the next GC, but I still see the old value of GC_stop_count
> (due to compiler or hardware memory reordering), I think it deadlocks.
> My ugly version will just pause for 25msecs and then recover.
> 
> I think I'll go with your version for GC7, where I have a cleaner
> way of enforcing the memory ordering, and keep my version for 6.6.
> (This assumes we find no other problems.  This stuff is much too
> subtle.)

Your patch had the fields set as volatile, so shouldn't the compiler
ensure that the cpu does not reorder the stores?

What if you only used one field for both the stop count and world is
stopped field (setting the flag for stopped on the highest bit). The
value is only modified in one thread at a time, so you don't have to CAS
or anything. The cpu would be forbidden from reordering writes (they
shouldn't reorder writes to the same field).

-- Ben



More information about the Gc mailing list