Subject: Re: [9fans] How it work?
Date: 2005年3月26日 2:08:14:JST
To: email@example.com, firstname.lastname@example.org
Reply-To: email@example.com, firstname.lastname@example.org
Rendezes are rendezvous points. Each Rendez r is protected
by a QLock r->l, which must be held by the callers of
rsleep, rwakeup, and rwakeupall. Rsleep atomically releases
r->l and suspends execution of the calling task. After
resuming execution, rsleep will reacquire r->l before
returning. If any processes are sleeping on r, rwakeup
wakes one of them. it returns 1 if a process was awakened,
0 if not. Rwakeupall wakes all processes sleeping on r,
returning the number of processes awakened. Rwakeup and
rwakeupall do not release r->l and do not suspend execution
of the current task.
Before use, Rendezes should be initialized to all zeros
except for r->l pointer, which should point at the QLock
that will guard r.
You're not locking the qlock first.
I can use lock, qlock and rendezvous without any problem but Rendez
don't work... if rsleep executed earlier than rwakeup, abort() cause
exception, stk() show:
rsleep ... /sys/src/libc/9sys/qlock.c:286
This line contain me = getqlp() in getqlp i find abort()...
You're being misled. The line that stk() shows is the
code that the call to abort will return to, which is
sometimes the next line of code. The actual
call is earlier, on line 283 or so:
/* we should hold the qlock */
/* add ourselves to the wait list */
me = getqlp();
Since getqlp wasn't on your stack frame, you can be
pretty sure that's not what called abort. (The Plan 9
compilers thankfully don't do any tail call elimination.)
in other way when rwakeup executed first, abort() ... stk() show:
rwakeup ... /sys/src/libc/9sys/qlock.c:329
which point me to another abort()
This time the line ref is correct.
Maybe it wrong initialization? But I also try other way... or I wrong
Well, yes. In addition to not locking the qlock before
calling rsleep or rwakeup, you're not actually checking
I guess this technically will work, but the standard usage
is that you're expecting some condition to happen, like
there's a shared queue and one thread is waiting for more
input and the other thread, which has just added to the queue,
wants to wake him. Commonly you see:
code depending on good condition
make condition good
It's like the sleep and wakeup in the kernel except that
the locking is a little different.
for a full example. It's an arbitrarily buffered queue.
The Rendez q->r is slept on by receivers waiting for
something to be put into the queue.