sched_lock && thread_lock()

[John Baldwin]

On Wednesday 23 May 2007 08:11:15 pm Jeff Roberson wrote:
> 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.

You have to have a spin lock with membar's across cpu_switch() so that 
curthread-private data is consistent after a thread migrates CPUs.  You only 
really need it for migrations if all your migrations are explicit, in which 
case a per-CPU lock for a migration queue where both CPUs (old first, then 
new second) lock the lock during the handoff.

-- 
John Baldwin