druntime thread_needLock()

[Leandro Lucarella]

Sean Kelly, el  5 de diciembre a las 23:33 me escribiste:
> 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.

FYI, I've added this to the druntime FAQ:
http://www.dsource.org/projects/druntime/wiki/DevelFAQ

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Karma police
arrest this man,
he talks in maths,
he buzzes like a fridge,
he's like a detuned radio.