Re: mutexes, locks and so on...

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

> On 2010-11-16 19:32, Eric Haszlakiewicz wrote:
>> On Tue, Nov 16, 2010 at 09:44:18AM -0800, Matt Thomas wrote:
>>> On Nov 16, 2010, at 9:10 AM, Alan Barrett wrote:
>>>> Please could somebody on the "eat your CAS whether you like it or not"
>>>> side of the fence explain why the following idea would not work:
>>>>
>>>> On Sat, 13 Nov 2010, der Mouse wrote:
>>>>> Arches without a sufficiently general CAS[%] do not define
>>>>> ATOMIC_OPS_USE_CAS and provides their own implementations of mutexes,
>>>>> spinlocks, whatever.
>>>
>>> Because that flexibility already exists.  A port can provide a full
>>> mutex or rwlock implementation or use the default based on CAS primitives.
>>>
>>> I think the question is about more about the naked use of atomic_cas_xxx
>>> which are scattered around in the kernel.
>>
>> Wouldn't those calls just use the slow implementation of CAS?  I haven't
>> heard anyone saying that the vax port shouldn't (continue to) implement ai
>> CAS operation, just that it shouldn't be used for mutexes.  And if those
>> naked uses of atomic_cas_xxx cause unreasonable slowness for that port,
>> well that's a separate problem.
> 
> Yes, for those cases in the kernel, where atomic_cas is used, there is 
> probably no option to continue providing a CAS implementation. Nothing 
> more to do or say about those ones.
> 
> The (my) problem is that rwlocks must use CAS as well, and I'm starting 
> to think that I have to use CAS for the mutex code as well, as I can't 
> seem to get mutexs work reliably without using the default 
> implementation. The mutexes are used and abused in ways that seems to 
> make a lot of implicit assumptions on the mutexes which go beyond what I 
> might expect. Still working on it, though.

- are you suggesting to revive __HAVE_SIMPLE_RW_LOCKS?

- hppa seems to have a mutex implemented without cas.  is it broken?

YAMAMOTO Takashi

> 
>       Johnny