pthread_mutex_lock / unlock affecting compiler optimization and/or caching ??
mynickmynick
or caching ??
in particular how could it increase cache ping-pong / false sharing??
thank you
Chris Thomasson
news:6fc6af0c-112c-442d...@w7g2000hsa.googlegroups.com...
> How could pthread_mutex_lock / unlock affect compiler optimization and/
> or caching ??
First, read this:
http://groups.google.com/group/comp.programming.threads/browse_frm/thread/63f6360d939612b3
The compiler must not move anything outside of the critical-section! Ouch.
> in particular how could it increase cache ping-pong
I guess certain lock implementations can increase cache coherency traffic
within the lock procedure itself. Think of spinlocks or adaptive mutexs
which lack appropriate backoff mechanisms.
> false sharing??
They can definitely increase false sharing if the lock state is not properly
padded to and aligned on L2 cache line boundaries; example:
http://groups.google.com/group/comp.programming.threads/msg/88bd832858072802
http://groups.google.com/group/comp.programming.threads/msg/9701b98be6ed6e7f
(run the program contained within that thread to see for yourself...)
mynickmynick
> > false sharing??
>
> They can definitely increase false sharing if the lock state is not properly
> padded to and aligned on L2 cache line boundaries; example:
>
>
> http://groups.google.com/group/comp.programming.threads/msg/9701b98be...
> (run the program contained within that thread to see for yourself...)
but this not on linux with pthread_mutex_lock, right?
Chris Thomasson
It certainly could be! If the `pthread_mutex_t' data-structures are not
properly
padded and aligned, well...
:^o