SODA Noriyuki wrote:

>>>>>>On Thu, 4 May 2006 11:51:05 +0200,
>>>>>>            
>>>>>>
>      Hans Petter Selasky <hselasky@c2i.net> said:
>
>  
>
>>How about using mutexes, like on FreeBSD, instead of splxxx?
>>    
>>
>
>FreeBSD (and Solaris)'s way makes kernel synchronization somewhat
>simpler, but it has certain drawbacks, e.g. it makes interrupt
>processing definitely slower.
>Also, I don't think using mutex helps this particular case much.
>  
>

I don't know about FreeBSD much, but the Solaris mechanism is well 
designed to support real SMP and properly has things like 
priority-inheritence to avoid priority inversion.  They are harder to 
use in drivers than splxxx(), because there is slightly more setup and 
tear down (each driver has its own mutexes, etc.)

The splxxx stuff is single processor legacy from the idea that you could 
just set the processor mask and that this was sufficient.

If we want to support true kernel SMP ever, then we need to go to 
mutexes or something like them. 

As far as performance goes, mutexes are not likely to be very different 
if design so that on uni processor platforms acquiring a mutex that has 
an "interrupt cookie" set for it (i.e. a mutex that protects data 
accessed in an ISR) degenerates into just doing the splxxx thing 
internally.  It should be possible (though less elegant) to make this 
even evaluate to splxxx() on those platforms without even an extra 
function call.  (Though you do have to add a branch test to determine 
whether to splxxx, and if so, at what level.)

Properly designed mutexes on SMP platforms cost more, due to 
mulitprocessor synchronization and the fact that drivers will tend to 
have a lot more calls to lock/unlock for fine-grained locking (to get 
better performance) than they typically do with just splxxx today.

    -- Garrett