Adam Conner-Sax Wrote:

> The attached code usually hangs (running on OSX, dmd 2.051).
> It uses spawn to create a new thread.  All the thread does is create a large
> array of doubles. In one case it uses the Array!double from std.container.  In
> the other case it uses the built in dynamic double[].  It declares the array,
> sets the length, then sends a message to main saying it is finished and exits.
> The Array!double case always runs fine.  The built-in dynamic array case
> usually hangs, though not always in the same place.
> And the array has to be sufficiently big (in my case 200000 or bigger I think)
> or the problem doesn't occur.
> I've no idea why.  It took me a *long* time to find this since it manifested
> as very mysterious hanging in a more complex piece of threaded code.  Now I've
> switched to using Array!double in my code and it all works fine.

This one is weird, and doesn't appear related to 4307.  One of the threads 
(thread A) is in a GC collection and blocked trying to acquire the mutex 
protecting the global thread list within thread_resumeAll.  Another thread 
(thread B) is also blocked trying to acquire this mutex for other reasons.  My 
best guess is that pthread_mutex in OSX is trying to give ownership of the lock 
to thread B, and since thread B is suspended it effectively blocks thread A 
from acquiring it to resume execution after the GC cycle.

Please submit a new issue for this.  I suspect this is OSX-specific, since OSX 
doesn't use signaling to coordinate stop-the-world collections (signaling 
*should* prevent a thread from being suspended while waiting for a mutex, while 
the suspend mechanism in OSX doesn't seem to).

Reply via email to