Re: [boost] [fiber] new version in vault

Subject: Re: [boost] [fiber] new version in vault
From: Helge Bahmann (hcb_at_[hidden])
Date: 2009-12-01 08:12:15

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.