tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: mutexes, locks and so on...

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.


Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email:             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Home | Main Index | Thread Index | Old Index