safe and threadsafe
wolfgang.thaller at gmx.net
Fri Feb 7 06:17:52 EST 2003
Simon Peyton-Jones wrote:
> That's a positive advantage, provided there isn't a massive efficiency
> cost. I'm all for nuking 'threadsafe' if we can!
Simon Marlow wrote:
> However, at the time I don't think we appreciated the implementation
> diffiulties arising from "safe".
After thinking about it a little, I'm not even ready to bet that "safe"
be that much faster than "threadsafe" for GHC...
Safe call-out can probably be optimized by not sending a signal
to a worker thread. (Worker thread spawning happens only the first time,
so it is not an issue).
Afterwards, we could immediately re-grab the "Capability" (without
and reenter the RTS, _unless_ there has been a call-in in the meantime.
We cannot do call-ins the same way as in the non-threaded RTS,
because when "threadsafe" calls are around, we cannot return from
schedule() (execution might have moved to a different worker).
After a call-in, the worker thread that was used to handle the call-in
still hold the capability and continue executing haskell code, so a
would have turned threadsafe. This might be difficult to prevent in
Also, the biggest piece of wasted performance that's currently lying
there is the locking for call-ins: give me a version of allocate that I
call with only the sched_mutex held (while STG code is executing in
thread), and I can cut the number of context switches for a call-in in
Simon PJ wrote:
> To be completely explicit, I think that increasing the safety level of
> any foreign import should never make the program fail.
I like that. Did I already mention that I think that the safest variant
be the default? ;-)
> | [...]
> | What should happen when C code running in a separate OS thread calls
> | foreign exported
> | function while the Haskell Runtime is blocked on a safe call?
> Would all these questions go away if we made safe=threadsafe?
Yes. All but the last one also go away when we keep the distinction,
but say that
"increasing the safety level [...] should never make the program fail".
More information about the FFI