druntime thread_needLock()

[Sean Kelly]

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