On 2008-12-06 09:44:06 +0100, Fawzi Mohamed <[EMAIL PROTECTED]> said:
On 2008-12-06 08:33:40 +0100, Sean Kelly <[EMAIL PROTECTED]> 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...
