tech-kern archive

[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:52, Matt Thomas wrote:

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.

That may be true in theory, but I happen to know (now) that it's not true in reality. I've found atleast one place in the kernel where this is done.

Oh, and mutex_vector_exit will not cause a panic, just because it was called from mmutex_spin_exit with a adaptive mutex. mutex_vector_exit will simply just handle it as an adaptive mutex, and release it.

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 

The VAX spin mutex code doesn't really need to change.  It's the adaptive mutex 
a challenge for MP.  The RAS CAS used on UP is likely going to be faster than 
alternative that you may come up with.

Well, I did fool around with the spin mutex code as well, since I was in there. But I also changed the adaptive mutexes, yes. I don't think in the end, the code that I have for spin mutexes is any different than the previous version.


Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email:             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Home | Main Index | Thread Index | Old Index