On 2010-11-16 18:44, 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:Consider this hypothetical: x86 does #define ATOMIC_OPS_USE_CAS and defines a CAS(); MI code notices this and defines all the higher-level primitives (if that's not too much of an oxymoron) in terms of CAS(). ppc, arm, all the arches sufficiently "modern" to have CAS, likewise. 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.
No, I don't think that is correct. While the mutex code is somewhat there, the rwlock is definitely not. But I'm also having problems with the mutex code right now. I'm trying to get it to work stable, but I've found, so far:
a spinlock mutex can be taken by mutex_spin_enter, and then released by a call to mutex_exit (not mutex_spin_exit). mutex_enter. If you define that you have your own mutex_spin functions, the kern_mutex.c still define a couple of macros, to take and release spin mutexes, and they are invoked by the general mutex_vector_{enter,exit} functions. If your mutexes are implemented in any other way than these macros define, your implementation will have problems. If your mutex_spin_enter code can't take a mutex, there is a mutex_spin_retry function in kern_mutex which you are expected to use(?), but this too assumes to know something of how your mutex works.
As for rwlocks, you simply cannot implement them without CAS, since in addition to the rwlock_enter, rw_lock_exit and rwlock_tryenter (which are the ones you can redefine) there are the upgrade, downgrade and other functions that always use CAS. But to make things worse, the exact layout of the structure and contents of the rwlock structure forces you to use CAS for the enter and exit functions as well, since you cannot have a separate lock for manipulating the rwlock. That would break the upgrade/downgrade code. And there is not even room in there for a lock on the rwlock itself. And the structure assumes you can atomically modify several fields in the same operation.
Johnny
--
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