Pavel Vasiliev wrote: [...] > I really think that having the only mutex for all short smart > pointer-related interlocked operations will not harm performance of > real-life applications in mp systems. In my code this mutex is used > only for really short operations like "lock, increment, save to > temporary, unlock, test the temporary". It is hard to imagine that > contention will often occur for so short operations.
Well, "raw" contention aside, with "ping-pong" I mean that with your design clients might rather quickly get into trouble with respect to "false sharing" effect(s) -- writing to "cache line" that is also held by another processor. The problem here is rather expensive communications needed to invalidate the other processor's cache-line, feed it with "up-to-date" data [that's most likely an additional "slow trip" to memory], etc. Well, you might want to take a look at: < "Performance Management Guide" [AIX 5L Version 5.1] > http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365c31.htm#HDRI42667 (Lock Granularity) http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365c31.htm#HDRI26126 (Cache Coherency) http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixbman/prftungd/2365c33.htm#HDRI14109 (Multiprocessor Throughput Scalability) < etc. "general" stuff from this publication > regards, alexander. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
