safe and threadsafe

Wolfgang Thaller wolfgang.thaller at
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 
safe call
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 
can safely
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 
> a
> | 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 mailing list