Maybe just remove the foot-shooting that releases it?

% Index: kern_sig.c % =================================================================== % RCS file: /home/ncvs/src/sys/kern/kern_sig.c,v % retrieving revision 1.170 % retrieving revision 1.171 % diff -u -1 -r1.170 -r1.171 % --- kern_sig.c 29 Jun 2002 02:00:01 -0000 1.170 % +++ kern_sig.c 29 Jun 2002 17:26:18 -0000 1.171 % @@ -1486,15 +1540,9 @@ % */ % - if (p->p_stat == SRUN) { % + mtx_unlock_spin(&sched_lock); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ shoot foot % + if (td->td_state == TDS_RUNQ || % + td->td_state == TDS_RUNNING) {

I think sched_lock is needed for checking td_state too (strictly to use the result of the check, so the lock is not critical if the use doesn't do anything harmful), but there is no lock indication for td_state in proc.h like there used to be for p_stat.

% + signotify(td->td_proc);

Holding sched_lock when calling signotify() used to be an error, but that was changed in rev.1.155. This signotify() call seems to be bogus anyway. signotify() should only be called after the signal mask is changed. The call to signotify() here was removed in rev.1.154 when the semantics of signotify() was changed a little. Bogus calls to signotify() just waste time.

% #ifdef SMP % - struct kse *ke; % - struct thread *td = curthread; % -/* we should only deliver to one thread.. but which one? */ % - FOREACH_KSEGRP_IN_PROC(p, kg) { % - FOREACH_KSE_IN_GROUP(kg, ke) { % - if (ke->ke_thread == td) { % - continue; % - } % - forward_signal(ke->ke_thread); % - } % - } % + if (td->td_state == TDS_RUNNING && td != curthread) % + forward_signal(td); % #endif

forward_signal() was called with sched_lock held in rev.1.170, and forward_signal() still requires it to be held. I think sched_lock is needed for checking td_state too, as above. Here it is fairly clear that calling forward_signal() bogusly after losing a race is harmless. It just wakes up td to look for a signal that isn't there or can't be handled yet. Since this only happens if we lose a race, it may be more efficient to let it happen (rarely) than to lock (always) to prevent it happening. But we already held the lock so the locking was free except for latency issues.