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