Re: [Caml-list] Severe loss of performance due to new signal handling

[Robert Roessler <roessler@rftp.com>]

Markus Mottl wrote:
> On 3/20/06, *Robert Roessler* <roessler@rftp.com 
> 
>     At the risk of being "irrelevant", I wanted to nail down exactly what
>     assertion is being made here: are we talking about directly executing
>     in assembly code the relevant x86[-64]/ppc/whatever instructions for
>     "read-and-clear", or going through OS-dependent access routines like
>     Windows' InterlockedExchange()?
> 
> 
> We are talking of the assembly code.  See file 
> byterun/signals_machdep.h, which contains the corresponding macros.

Thanks, Markus - in the case you cite (direct instruction use), I was 
hoping for some illumination on this huge cost... reviewing the Intel 
manuals, I note that:

1) there is *no* claim that cache lines are flushed just by doing the xchg

2) in fact, with the Pentium Pro on, the bus LOCK# operation will not 
even happen if the data is cached - everything is left to the cache 
coherency mechanism

3) there *is* mention of processor *cache locking*, but this is still 
just in the context of cache coherency with multiple processors... so 
nothing here is suggesting cache line flushing or anything else that 
sounds horrendously expensive, particularly in the single CPU case

< 8 hours later, back to finish email :) >

Finally, it is interesting that you bring up this file - it appears as 
if the msvc toolchain is no longer supported for doing "correct" (in 
terms of Xavier's "atomicity w.r.t. signals") builds... at least that 
is how I interpret the conditional compilation directives.

Robert Roessler
roessler@rftp.com
http://www.rftp.com