On 2010-11-17 04:25, matthew green wrote:
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.can you expand upon the problems? i'm curious if they match what we found with sparc long ago (but my memory is not really working well for that right now... :)
I did sum up what I've found out so far, but as the code is still not working reliably, my observations should be taken with a grain of salt.
But first of all, any mutex seems to be both taken and release through both mtex_enter and mutex_spin_enter, and it can be done assymetrically. So a mutex might be taken with mutex_spin_enter, and then released with mutex_exit.
Also, the taking of spin mutexes can be done in mutex_vector_enter, and that will use a definition for how a spin mutex is taken based on a macro that is defined within kern_mutex.c, so spin mutexes can be dangerous for your sanity.
I have gotten the code to work, but a few minutes after boot, the system gets stuck on a spin mutex already held. The code I replaced don't even check for that condition, so I'm not sure what is going on here, but it might be that there is some semi-obscure bug that was not causing any real problems previously.
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