svn commit: r202889 - head/sys/kern

M. Warner Losh imp at bsdimp.com
Tue Jan 26 20:15:30 UTC 2010


In message: <C6A8F7A7-F0A9-4F63-B61E-DDC5332DC495 at mac.com>
            Marcel Moolenaar <xcllnt at mac.com> writes:
: 
: On Jan 26, 2010, at 3:39 AM, Attilio Rao wrote:
: >>> 
: >>> Does this affect the various #ifdef's for handling the third argument to
: >>> cpu_switch()?  E.g. does 4BSD need to spin if td_lock is &blocked_lock?
: >>> 
: > 
: > I think that ia64 is broken on that regard because it does use simple
: > operation while it should use correct atomic and memory barriers
: > (CC'ed marcel@ for that).
: 
: Ok, so cpu_switch() handles the 3rd argument (the mutex) only
: when SCHED_ULE and SMP are defined, even on i386. Maybe it's
: just me, but if SCHED_4BSD now also uses the 3rd argument then
: all implementations of cpu_switch() are broken, right?

No.  The current implementations always STORE the argument.  One only
loops if newthread->td_lock == blocked_lock.  which is something
else.  That was part of my initial confusion as well...

: Maybe what is in order right now is a description (using pseudo
: code if you like) of what exactly needs to happen with the 3rd
: argument, when and how (i.e. what must be atomic and what does
: not have to be atomic).

I believe the proper pseudo code should be:

cpu_switch(struct thread *old, struct thread *new, struct mutext *mtx)
{
	/* Save the registers to the pcb */
	old->td_lock = mtx;
#if defined(SMP) && defined(SCHED_ULE)
	/* s/long/int/ if sizeof(long) != sizeof(void *) */
	/* as we have no 'void *' version of the atomics */
	while (atomic_load_acq_long(&new->td_lock) == (long)&blocked_lock)
		continue;
#endif
	/* Switch to new context */
}

although the #ifdef might not actually be strictly necessary (eg, 4BSD
doesn't migrate threads like ULE does, so you don't hit the case of
having to wait for the new thread to become unblocked).  At least
that's the impression I have after reading Atillio's email on this
topic.

I also think that we should have that code somewhere for reference.
When I was bringing up the MIPS code from the 6.1 base to -current,
the third argument made no sense to me at all, so I didn't implement
it at all.  Someone (gonzo@?) tried to implement it, but it was found
recently to have been implemented wrong.  That's been fixed now, and
as part of fixing it, I started asking questions...

: I can deal with ia64 and powerpc once I know for certain what
: exactly needs to happen, because it seems to me that I can't
: really look at the i386 implementation and infer what needs to
: happen.

I think that the only difference between what mips has now and what is
needed is that mips implements the while loop as approximately:
	while ((volatile)new->td_lock == &blocked_lock)
		continue;
so I need to figure out the right memory barrier assembler instruction
to make this right.  I think sync might be it for mips, but maybe it
is sync or some other processor dependent instruction (Cavium has
special instructions for things like this with more tailored
semantics, for example).

Warner


More information about the svn-src-head mailing list