RE: mutex blocking queues..
this strikes me as avoidable. I'll think about it.. Until then
I guess I'll just have two lists in the thread.. one for sleep and one for
mutexes.
On Mon, 23 Jul 2001, John Baldwin wrote:
On 23-Jul-01 Julian Elischer wrote:
Why does the mutex not link blocked processes though the
sleep queue linked list entry? Why does it use the run queue entry?
In KSEs the sleep queue and run queue enties go into different
sub structures and ahve different types so this breaks...
do I need to do something sleazy or can I just link them together using the
equivalemt of the p_slpq entry?
You can block on a mutex when processing signals in the catch case in msleep()
after you have put the process on the sleep queue:
int
msleep(ident, mtx, priority, wmesg, timo)
{
...
p-p_wchan = ident;
p-p_wmesg = wmesg;
p-p_slptime = 0;
p-p_pri.pri_level = priority PRIMASK;
CTR5(KTR_PROC, msleep: proc %p (pid %d, %s) on %s (%p), p, p-p_pid,
p-p_comm, wmesg, ident);
TAILQ_INSERT_TAIL(slpque[LOOKUP(ident)], p, p_slpq);
...
/*
* We put ourselves on the sleep queue and start our timeout
* before calling CURSIG, as we could stop there, and a wakeup
* or a SIGCONT (or both) could occur while we were stopped.
* A SIGCONT would cause us to be marked as SSLEEP
* without resuming us, thus we must be ready for sleep
* when CURSIG is called. If the wakeup happens while we're
* stopped, p-p_wchan will be 0 upon return from CURSIG.
*/
if (catch) {
CTR3(KTR_PROC, msleep caught: proc %p (pid %d, %s), p,
p-p_pid, p-p_comm);
p-p_sflag |= PS_SINTR;
mtx_unlock_spin(sched_lock);
PROC_LOCK(p);
sig = CURSIG(p);
mtx_lock_spin(sched_lock);
PROC_UNLOCK_NOSWITCH(p);
...
If that proc_lock blocks then we don't want to clobber the sleep queue.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mutex blocking queues..
Jake Burkholder wrote: Why does the mutex not link blocked processes though the sleep queue linked list entry? Why does it use the run queue entry? Because in some cases its necessary for a process to acquire mutexes while its on the sleep queue. If they used the same linkage the queues would get corrupted. can this be fixed? In KSEs the sleep queue and run queue enties go into different sub structures and ahve different types so this breaks... do I need to do something sleazy or can I just link them together using the equivalemt of the p_slpq entry? It seems to me that whatever gets placed on the run queues should also be what goes on the mutex queues. it would at first glance, but it is not the case when you think about it.. threads sleep/block, but the process is still on the run queue If you put all threads in the run queue, then when one runs you need to remove all the others from the queue and then add them again if they didn't get run at that quanta.. better to add the 'kse' onto the queue once, and hang all it's runnable threads off it.. -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mutex blocking queues..
Why does the mutex not link blocked processes though the sleep queue linked list entry? Why does it use the run queue entry? In KSEs the sleep queue and run queue enties go into different sub structures and ahve different types so this breaks... do I need to do something sleazy or can I just link them together using the equivalemt of the p_slpq entry? -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: mutex blocking queues..
On 23-Jul-01 Julian Elischer wrote:
Why does the mutex not link blocked processes though the
sleep queue linked list entry? Why does it use the run queue entry?
In KSEs the sleep queue and run queue enties go into different
sub structures and ahve different types so this breaks...
do I need to do something sleazy or can I just link them together using the
equivalemt of the p_slpq entry?
You can block on a mutex when processing signals in the catch case in msleep()
after you have put the process on the sleep queue:
int
msleep(ident, mtx, priority, wmesg, timo)
{
...
p-p_wchan = ident;
p-p_wmesg = wmesg;
p-p_slptime = 0;
p-p_pri.pri_level = priority PRIMASK;
CTR5(KTR_PROC, msleep: proc %p (pid %d, %s) on %s (%p), p, p-p_pid,
p-p_comm, wmesg, ident);
TAILQ_INSERT_TAIL(slpque[LOOKUP(ident)], p, p_slpq);
...
/*
* We put ourselves on the sleep queue and start our timeout
* before calling CURSIG, as we could stop there, and a wakeup
* or a SIGCONT (or both) could occur while we were stopped.
* A SIGCONT would cause us to be marked as SSLEEP
* without resuming us, thus we must be ready for sleep
* when CURSIG is called. If the wakeup happens while we're
* stopped, p-p_wchan will be 0 upon return from CURSIG.
*/
if (catch) {
CTR3(KTR_PROC, msleep caught: proc %p (pid %d, %s), p,
p-p_pid, p-p_comm);
p-p_sflag |= PS_SINTR;
mtx_unlock_spin(sched_lock);
PROC_LOCK(p);
sig = CURSIG(p);
mtx_lock_spin(sched_lock);
PROC_UNLOCK_NOSWITCH(p);
...
If that proc_lock blocks then we don't want to clobber the sleep queue.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
