Runtime performance degradation for multi-threaded C FFI callback

[Edward Z. Yang]

Hmm, this kind of sounds like GHC is assuming that it has control over
all of the threads, and when this assumption fails bad things happen.
(We use lightweight threads, and use the operating system threads that
map to pthreads sparingly.)  I'm sure Simon Marlow could give a more accurate
assessment, however.

Edward

Excerpts from Sanket Agrawal's message of Tue Jan 17 23:31:38 -0500 2012:
> I posted this issue on StackOverflow today. A brief recap:
> 
>  In the case when C FFI calls back a Haskell function, I have observed
> sharp increase in total time when multi-threading is enabled in C code
> (even when total number of function calls to Haskell remain same). In my
> test, I called a Haskell function 5M times using two scenarios (GHC 7.0.4,
> RHEL5, 12-core box):
> 
> 
>    - Single-threaded C function: call back Haskell function 5M times -
>    Total time 1.32s
>    - 5 threads in C function: each thread calls back the Haskell function 1M
>    times - so, total is still 5M - Total time 7.79s - Verified that pthread
>    didn't contribute much to the overhead by having the same code call a C
>    function instead, and compared with single-threaded version. So, almost all
>    of the increase in overhead seems to come from GHC runtime.
> 
> What I want to ask is if this is a known issue for GHC runtime? If not,  I
> will file a bug report for GHC team with code to reproduce it. I don't want
> to file a duplicate bug report if this is already known issue. I searched
> through GHC trac using some keywords but didn't see any bugs related to it.
> 
> StackOverflow post link (has code and details on how to reproduce the
> issue):
> http://stackoverflow.com/questions/8902568/runtime-performance-degradation-for-c-ffi-callback-when-pthreads-are-enabled