druntime thread_needLock()

[Fawzi Mohamed]

On 2008-12-06 09:44:06 +0100, Fawzi Mohamed <fmohamed at mac.com> said:

> On 2008-12-06 08:33:40 +0100, Sean Kelly <sean at invisibleduck.org> said:
> 
>> dsimcha wrote:
>>> According to both the docs and my own experiments, thread_needLock() in
>>> core.thread returns a bool that depends on whether the current process has
>>> *ever* been multithreaded at *any* point in its execution.  In Phobos's GC
>>> (pre-druntime), a similar function existed, but it returned a bool based on
>>> whether more than 1 thread was *currently* running.  It seems to me that
>>> omitting locks should be safe if no more than 1 thread is currently running,
>>> even if more than 1 was running at some point in the past.  Why is druntime's
>>> thread_needLock() designed the way it is?
>> 
>> Typically, the stores of a terminating thread are only guaranteed to be 
>> visible when join() returns for that thread... and then to the joining 
>> thread only.  While it's true that the stores will eventually be 
>> visible to all threads in a program, there's no easy way to figure out 
>> exactly when this is (the lock-free people would probably say you'd 
>> have to wait for a "quiescent state").  I also don't know of any apps 
>> that are multi threaded for a while and then later become single 
>> threaded, so the issue of performance loss seems like somewhat of a 
>> corner case.
>> 
>> 
>> Sean
> 
> ok so this is the reason, good to know...
> 
> Fawzi

a memory barrier would be needed, and atomic decrements, but I see that 
it is not portable...