druntime thread_needLock()

[Fawzi Mohamed]

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