Le 26/12/2011 20:49, Andrei Alexandrescu a écrit :
On 12/26/11 12:46 PM, Michel Fortin wrote:
Although I am a little concerned by this
small but important implementation detail:
Your RefCounted destructor is racy.
Just like other reference counted things in Phobos, if you somehow store
a reference on the GC heap (as a class member for instance), the
destructor for that reference struct is called from the GC thread and
will decrement the counter from that thread, while another reference
could play with the counter from another thread. I know you have plans
for a general fix for that hole in destructors, but meanwhile it'd be
wise to change the counter to a shared uint and use atomic operations to
avoid low level races.
Does the current implementation unfreezes all threads before calling the
destructors? If so, indeed there's a race.
BTW, the plan is to have the same thread that constructed objects to
call their destructors; each thread would have a worklist of garbage
objects to destroy. The list can be reduced during calls to allocation
functions within each thread, and of course when the thread terminates.
Andrei
This is nice for thread local data, but does it make sense for
immuables/shared ?
I'm not sure this design is secure regrading GC. What happen if the
destructor of the RefCounted is called, (and will call dispose) and then
the payload is destructed. We have a risk of double destruction.
