On 2008-12-06 06:02:44 +0100, dsimcha <[EMAIL PROTECTED]> 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
