[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: mutexes, locks and so on...
On 2010-11-17 04:13, YAMAMOTO Takashi wrote:
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,
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?
I don't know, since I don't know the details of that.
But I'd be happy if rwlocks were just possible to implement in a way
that was sensible on a VAX, as an alternative to the current
implementation. Essentially having rwlock being defined by the
operations (enter,exit,tryenter,upgrade,downgrade), and then let the
current implementation continue to look as it is, but having it possible
to replace all of it, and not just some small parts which makes it
currently pretty meaningless.
- hppa seems to have a mutex implemented without cas. is it broken?
I don't know, but would be very interested to hear from someone running
-current on hppa. hppa is the only architecture currently implementing
it's own mutex code, and I have peeked quite some on that code for mine...
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Main Index |
Thread Index |