> I have ignored the BHL by the comparison of various states as you told.
> But still dealing with BHL is not completely clear to me.
Now that I look again at the MSMHelgrind code, I have to admit I do
not understand the BHL kludges I put in it :-( In particular I cannot
see why msm__handle_read uses add_BHL.
I can only suggest that you ignore what MSMHelgrind does and
figure it out yourself from first principles.
I think what MSMHelgrind tries to do is handle the BHL as if it
was a normal mutex, iow a writer-lock. This is more restrictive
than how the hardware behaves, but at least it is simple. THe
hardware requires a LOCK prefix only for writes or modifies of
shared locations; reading does not require a lock.
The instrumentation function (hg_instrument, instrument_memory_bus_event)
creates calls to evh__bus_{lock,unlock} around every LOCK-prefixed
instruction. And those behave exactly as if the program had
called "pthread_mutex_lock( &__bus_lock )" /
"pthread_mutex_unlock( &__bus_lock )".
This means the bus lock handling is more restrictive than for the
real hardware. It requires readers to hold the lock (iow, to use
a LOCK prefix) even though this is not required by the h/w.
Other than that, I don't think I can tell you anything useful.
If you have any insights, and/or if you can figure out a way to model
the h/w more accurately than described above, I would be interested
to hear. I suggest also playing with tc07_hbl1.c and tc08_hbl2.c
as they are simple programs and the behaviour should be easy
to understand.
J
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
