sched_lock && thread_lock()

[Jeff Roberson]

On Wed, 23 May 2007, Marcel Moolenaar wrote:

>
>>> The old patch was missing PowerPC & ia64. Will the final version
>>> include those as well?
>> 
>> There are a couple of uses of the global scheduler lock in some 
>> architecture specific locations.  They will continue to be safe with the 
>> 4BSD scheduler.  I intended to work on these issues with the architecture 
>> maintainers after the threadlock patch goes in.  Can you suggest some 
>> alternative to sched_lock for pmap_switch in ia64?
>
> pmap_switch() is called from cpu_switch() and from pmap_install().
> So, currently, pmap_install() grabs sched_lock to mimic the
> cpu_switch() path and we assert having sched_lock in pmap_switch().
> Basically, any lock that serializes cpu_switch() would work, because
> we don't want to switch the thread while in the middle of setting up
> the region registers.

We could simply use thread_lock() now if this serialization only applies 
to preventing multiple access to the same thread.

>
>> There are a couple of these small issues that should be perfectly safe that 
>> I was hoping to address outside of this patch so that it didn't get too 
>> big.
>
> I noticed you introduced sched_throw(). Would it harm if ia64
> doesn't yet use sched_throw() and instead has the sequence it
> replaces? In other words: is the initial implementation of
> sched_throw() the same as the current code?

The problem is that sched_throw() must acquire the correct scheduler lock 
before entering cpu_throw().  That's why I moved it into the per-scheduler 
code.  sched_smp, which is the updated ule, acquires the correct lock for 
the current cpu.

Jeff

>
> -- 
> Marcel Moolenaar
> xcllnt at mac.com
>