On Nov 16, 2010, at 7:32 PM, Johnny Billquist wrote:
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.
Not true. Spinlocks must enter through mutex_spin_enter and adaptive mutexes
enter through mutex_enter. The corresponding is true for exiting as well.
The only reason mutex_vector_{enter,exit} is called to cause a panic.
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.
The VAX spin mutex code doesn't really need to change. It's the adaptive mutex
that's
a challenge for MP. The RAS CAS used on UP is likely going to be faster than
any
alternative that you may come up with.