From: James Bottomley <James.Bottomley@steeleye.com>
To: David Brownell <david-b@pacbell.net>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Mike Anderson <andmike@us.ibm.com>, Andrew Morton <akpm@osdl.org>,
greg@kroah.com, Jens Axboe <axboe@suse.de>,
linux-usb-devel@lists.sourceforge.net,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [linux-usb-devel] Re: bug 2400
Date: 05 Apr 2004 20:19:18 -0500 [thread overview]
Message-ID: <1081214360.1756.330.camel@mulgrave> (raw)
In-Reply-To: <4071EA82.3020901@pacbell.net>
On Mon, 2004-04-05 at 18:23, David Brownell wrote:
> "Irrelevant" is pointlessly strong, even for what I'm guessing
> you really mean to be saying.
No, it's the very point.
If we have to enforce ordering on the event propagation across
subsystems, that can't be done without inter subsystem synchronisation.
In order to get away without any inter subsystem synchronisation the
order has to not matter. i.e. be irrelevant.
> Minimally, there needs to be synchronization to prevent open() on
> one CPU from using data structures disconnect() just invalidated
> on another CPU. That's a basic "how to write multi-threaded code"
> kind of issue, which I won't bother to explain (yet again).
Yes, but that's intra subsystem synchronisation, not inter subsystem
synchronisation.
Look, the rules are very simple:
- Every subsystem gives out refcounted objects.
- Every subsystem takes in a disconnection event for another object.
Now what the subsystem does with the event is up to it. The only
guarantee is if the subsystem holds no references to the other object
after the disconnection completes in that subsystem, then it may be
garbage collected. However, if not, the other object must remain until
the last reference is dropped.
The point is that all the disconnection event does is inform a subsystem
that the entity represented by the other object has gone. What it
chooses to do with the information is up to it. It could set it's own
connected object to degraded, never use the other object again and drop
the reference. Or, it could simply ignore the indication and continue
to use the other object (even though it will return errors for every
operation).
Now, if the subsystem is going to garbage collect its own object as a
result of the other object disconnect, then it is responsible for
synchronising that with reference gets on its own object. However, that
is easily achievable via *intra* subsystem synchronisation.
If you follow these rules, there's no *inter* subsystem ordering or
synchronisation requirement.
James
next prev parent reply other threads:[~2004-04-06 1:19 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-01 21:15 bug 2400 Andrew Morton
2004-04-01 21:52 ` Matt Gulick
2004-04-01 22:08 ` Andrew Morton
2004-04-01 22:48 ` Matt Gulick
2004-04-01 22:40 ` James Bottomley
2004-04-01 22:53 ` Matt Gulick
2004-04-01 23:07 ` Matthew Dharm
2004-04-01 23:32 ` James Bottomley
2004-04-02 0:29 ` Steven Dake
2004-04-02 8:43 ` Mike Anderson
2004-04-02 15:57 ` James Bottomley
2004-04-02 16:45 ` Mike Anderson
2004-04-02 17:05 ` James Bottomley
2004-04-02 17:44 ` Mike Anderson
2004-04-02 18:13 ` James Bottomley
2004-04-02 23:40 ` Mike Anderson
2004-04-03 0:25 ` James Bottomley
2004-04-04 1:40 ` Alan Stern
2004-04-04 15:23 ` James Bottomley
2004-04-04 16:46 ` Alan Stern
2004-04-04 17:04 ` James Bottomley
2004-04-05 3:17 ` Alan Stern
2004-04-05 14:59 ` Mike Anderson
2004-04-05 21:27 ` James Bottomley
2004-04-06 14:00 ` Alan Stern
2004-04-05 22:10 ` Patrick Mansfield
2004-04-06 14:10 ` Alan Stern
2004-04-08 14:09 ` Alan Stern
2004-04-08 16:24 ` Matt Gulick
2004-04-08 18:33 ` Alan Stern
2004-04-08 19:44 ` Matt Gulick
2004-04-05 13:30 ` [linux-usb-devel] " Oliver Neukum
2004-04-04 18:16 ` David Brownell
2004-04-04 18:42 ` James Bottomley
2004-04-05 3:54 ` David Brownell
2004-04-05 21:44 ` James Bottomley
2004-04-05 23:23 ` [linux-usb-devel] " David Brownell
2004-04-06 1:19 ` James Bottomley [this message]
2004-04-06 6:52 ` Oliver Neukum
2004-04-06 14:03 ` James Bottomley
2004-04-07 9:19 ` Oliver.Neukum
2004-04-06 15:10 ` David Brownell
2004-04-06 15:47 ` James Bottomley
2004-04-06 16:16 ` David Brownell
2004-04-06 16:55 ` Alan Stern
2004-04-06 17:13 ` James Bottomley
2004-04-02 23:36 ` James Bottomley
2004-04-03 0:11 ` Mike Anderson
2004-04-03 0:16 ` James Bottomley
2004-04-05 4:33 ` Patrick Mansfield
2004-04-05 14:09 ` James Bottomley
2004-04-05 21:07 ` James Bottomley
2004-04-06 9:22 ` Jens Axboe
2004-04-06 13:56 ` James Bottomley
2004-04-06 14:04 ` Jens Axboe
2004-04-06 14:09 ` James Bottomley
2004-04-08 23:06 ` Greg KH
2004-04-09 11:28 ` James Bottomley
2004-04-05 14:03 ` Jens Axboe
2004-04-05 21:08 ` James Bottomley
2004-04-06 9:22 ` Jens Axboe
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=1081214360.1756.330.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=akpm@osdl.org \
--cc=andmike@us.ibm.com \
--cc=axboe@suse.de \
--cc=david-b@pacbell.net \
--cc=greg@kroah.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.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