On Tue, 1 Dec 2009, Stefan Strasser wrote:
Am Tuesday 01 December 2009 13:18:19 schrieb Helge Bahmann:
On Tue, 1 Dec 2009, Stefan Strasser wrote:
Am Tuesday 01 December 2009 11:05:26 schrieb Helge Bahmann:
A hashed lock library would be welcome here, I'm sure.
Yes, this would be a really helpful addition to Boost.Thread -- implementing fallback for atomic operations is just not feasible without.
could you explain this please? I use something like that myself, as a workaround, but I don't see how that is a desired solution. why would you hash to access something that should be one word in size?
There must be a fallback implementation if the processor cannot perform an operation atomically -- and the template argument to atomic<> may for example be a double-word which not every processor can access atomically.
that's undisputed. my question was referring to a hashed lock library being a good addition to boost. why would you want to use hashed mutexes when you can implement a mutex in the size of a reference into a mutex table?
Implementing a mutex requires atomic operations, so this just recurses the problem in case no atomic ops are available :) I don't want to store references into a mutex table anywhere -- the goal is to make atomic objects the exact size of their non-atomic counterpart (possibly padded to word size), and hash an object's address on access to map it to an entry of a fixed preallocated mutex table.