druntime thread_needLock()

[Fawzi Mohamed]

On 2008-12-06 06:02:44 +0100, dsimcha <dsimcha at yahoo.com> said:

> 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?

Indeed I see no real reason not to keep a thread could that would be 
incremented before spawn or in thread_attach, and decremented at the 
end of thread_entryFunction and thread_detach.

Potentially one could think badly written code similar to this
  if (thread_needLock()) lock();
  if (thread_needLock()) unlock();
or initializations done unconditionally when the runtime becomes multithreaded,
but I found no issues like this in tangos runtime, thread_needLock is 
used only to then do synchronized(...){...}

So yes one could probably switch back to the old Phobos style.
I would guess that it is not really a common situation for a program to 
become single threaded again, though...

Fawzi