[Haskell-cafe] Why do "unsafe" foreign calls block other threads?

Gregory Crosswhite gcross at phys.washington.edu
Tue Aug 3 19:03:11 EDT 2010


 OHHHHHHHHHHHHHHHH, okay, that makes a LOT more sense!  I had thought
that "blocking" meant that *all* of the *OS* threads were halted before
making the call, but if "blocking" really just means that the calling
*OS* thread can't do any other work until the call returns (hence
blocking the other *IO* threads mapped to that OS thread) then it all
makes sense to me.  :-)

Cheers,
Greg

On 08/03/10 15:49, Gábor Lehel wrote:
> As far as I know, it works like this:
>
> "unsafe" calls are just executed directly, like any other C function
> call; as a result, any lightweight haskell threads which were mapped
> onto the OS thread in which the call is made are blocked for the
> duration of the call; hence why it's a good idea that these calls
> should be short ones. So the blocking is not by intent, but -is- a
> direct consequence (of how unsafe calls are made and how GHC's
> threading system works). Other OS threads and the haskell threads
> mapped to them are not blocked, afaik.
>
> "safe" calls spawn a new OS thread (maybe reuse an existing one if
> available?), move the haskell threads over, (do various other
> housekeeping?), and then make the call.
>
> On Wed, Aug 4, 2010 at 12:41 AM, Gregory Crosswhite
> <gcross at phys.washington.edu> wrote:
>>  On 08/03/10 15:33, Evan Laforge wrote:
>>>>> Just think of "unsafe" in relation to "unsafeIndex" or something.
>>>>> It's faster, but you have to be sure the index is in bounds.
>>>> Yes, but the whole reason to use "unsafe" is to get higher performance
>>>> at the cost of safety.  If the result of calling an "unsafe" foreign
>>>> function is that you *lose* performance because the other threads have
>>>> to be halted first, then this seems to defeat the whole point of marking
>>>> a call as "unsafe" in the first place.
>>> That's why the function has to return soon and shouldn't do a lot of work.
>> But again, then what is the point of marking it "unsafe" if it means
>> that you have to pay a hefty cost of waiting for all the other threads
>> to halt?  Is the cost of halting all of the other threads really less
>> than the cost of setting up for a "safe" call?  Maybe it is, and that is
>> what I am missing here.  If it is not, though, then it seems to me that
>> marking a call as "unsafe" will *never* gain you performance in a
>> multi-threaded environment, so that there is never any point in using it
>> in such an environment.  (Though, of course, it could gain you
>> performance in a single-threaded environment.)
>>
>> Cheers,
>> Greg
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>



More information about the Haskell-Cafe mailing list