From: miller@hamnavoe.demon.co.uk
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Kernel question: i386 test-and-set problem
Date: Thu, 20 Jul 2000 14:54:57 +0100 [thread overview]
Message-ID: <E13FGjC-0007j3-0Y@anchor-post-34.mail.demon.net> (raw)
jmk@plan9.bell-labs.com writes:
> The sleep/wakeup/postnote Rendez structure still has a lock which
> protects it, it just moved somewhere else.
Sorry, I didn't explain in enough detail. In /sys/src/9/port/proc.c:588
wakeup() looks at r->p (pointer from Rendez to sleeping process)
without first acquiring any lock. That's the unprotected access I was
referring to: it's dangerous because r->p is shared asynchronously
by sleep() and postnote().
The original 2nd edition kernel (CD version) had a lock in the Rendez
structure, and all accesses to r->p were protected by acquiring
the lock first. However, p->r (pointer from sleeping process to Rendez)
was shared between sleep() and postnote() without locking.
A later kernel update (845586056.rc) introduced a new lock in the Proc
structure (p->rlock) to protect the shared access to p->r, but eliminated
the lock in the Rendez structure. This left r->p exposed again. I believe
that's why you need coherence() calls.
> The 2nd Edition code would
> have needed coherence() calls too, but in different places, had it not
> been rewritten before we tried running on a multiprocessor Pentium Pro.
When I added mp support to the 2nd edition for my dual ppro system,
I reinstated the Rendez lock, and kept p->rlock as well, so in the
three-way conversation between sleep(), wakeup() and postnote() both
r->p and p->r are protected. I didn't add any explicit coherence()
calls anywhere, and the system has been running stably for over two years.
If I remove the lock around the r->p access in wakeup(), a few simultaneous
'du -a /' commands will quickly cause a crash.
-- Richard Miller
next reply other threads:[~2000-07-20 13:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-20 13:54 miller [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-08-03 9:56 miller
2000-08-02 16:24 presotto
2000-08-02 15:43 jmk
2000-08-02 14:51 miller
2000-08-02 13:20 presotto
2000-08-02 8:32 miller
2000-07-31 17:26 presotto
2000-07-23 14:41 miller
2000-07-21 13:15 presotto
2000-07-21 9:10 miller
2000-07-20 17:09 presotto
2000-07-20 2:03 jmk
2000-07-10 16:21 miller
2000-07-10 12:40 Russ Cox
2000-07-11 8:51 ` Jakub Jermar
2000-07-10 9:57 Jakub Jermar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E13FGjC-0007j3-0Y@anchor-post-34.mail.demon.net \
--to=miller@hamnavoe.demon.co.uk \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).