linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Richard B. Johnson" <root@chaos.analogic.com>
To: Robert Love <rml@tech9.net>
Cc: Paul Mackerras <paulus@samba.org>,
	Patrick Mochel <mochel@osdl.org>, Greg KH <greg@kroah.com>,
	Andrew Morton <akpm@digeo.com>,
	sdake@mvista.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] udev enhancements to use kernel event queue
Date: Fri, 13 Jun 2003 08:44:52 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.53.0306130823170.4004@chaos> (raw)
In-Reply-To: <1055461816.662.350.camel@localhost>

On Thu, 12 Jun 2003, Robert Love wrote:

> On Thu, 2003-06-12 at 16:40, Paul Mackerras wrote:
>
> > BZZZT.  If another CPU is also doing atomic_inc_and_read you could end
> > up with both calls returning the same value.
>
> That is what I thought. Damn.
>
> > You can't do atomic_inc_and_read on 386.  You can on cpus that have
> > cmpxchg (e.g. later x86).  You can also on machines with load-locked
> > and store-conditional instructions (alpha, ppc, probably most other
> > RISCs).
>
> So this is doable on everything but old i386 chips... hrm.
>
> 	Robert Love
>

No! They do not return the same value. They just don't return the
final value, and the final value might not be important if the
atomic operations are used correctly.

The atomic stuff is to get rid of the read/modify/write problem where
you have a read *INTERRUPT* (other read, other modify, other write),
modify, write. Now the operand is nothing like expected. The
atomic operations guarantee that the memory operand will, in fact,
be completely modified as expected. Reading any value after such
modification does not necessarily return the final value because
somebody could modify it (again atomically), before you get
a chance to read it.

So, if you have N atomic_inc() and N atomic_dec() operations, the
value will be whatever it was before the first operation. In other
words, the value will be correct.

FYI, all memory modify operations, not using an intermediate register,
in  32-bit mode, of a longword or less, on ix86 machines are atomic,
even without the lock prefix.

like:

memory:	.long	0
	incl (memory)
	incw (memory)
	incb (memory)

This is because the CPU does not load the operand, modify it, then
write it back. It might "physically" do this in hardware, but the
physical operation cannot be interrupted until complete. So, in
principle, the lock instruction isn't necessary for things like above.

If you really need to know what the value of the memory operand
was at the instant it was modified, you need use the locked/exchange
instructions. Normally, you don't need to know the exact value
of some semaphore, etc., only that some conditions were true or
false at the instant of a test.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.


  reply	other threads:[~2003-06-13 12:29 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-12 19:10 [PATCH] udev enhancements to use kernel event queue Steven Dake
2003-06-12 21:47 ` Patrick Mochel
2003-06-13 16:31   ` Steven Dake
2003-06-13 17:06     ` Patrick Mochel
2003-06-12 21:47 ` Greg KH
2003-06-12 22:03   ` Andrew Morton
2003-06-12 22:50     ` Greg KH
2003-06-12 22:51       ` Andrew Morton
2003-06-12 23:02         ` Greg KH
2003-06-12 23:09           ` Greg KH
2003-06-12 23:14             ` Patrick Mochel
2003-06-12 23:16             ` Robert Love
2003-06-12 23:25               ` Greg KH
2003-06-13 20:01                 ` Oliver Neukum
2003-06-18 22:59                   ` Greg KH
2003-06-19  0:12                     ` Kevin P. Fleming
2003-06-19  0:20                       ` Greg KH
2003-06-19  0:42                         ` Kevin P. Fleming
2003-06-19  0:51                           ` Greg KH
2003-06-19  0:25                       ` Andrew Morton
2003-06-19  6:27                       ` Oliver Neukum
2003-06-12 23:25               ` Patrick Mochel
2003-06-12 23:29                 ` Robert Love
2003-06-12 23:32                   ` Greg KH
2003-06-12 23:34                   ` Patrick Mochel
2003-06-12 23:40                     ` Paul Mackerras
2003-06-12 23:50                       ` Robert Love
2003-06-13 12:44                         ` Richard B. Johnson [this message]
2003-06-13 12:54                           ` Olivier Galibert
2003-06-12 23:52                       ` Patrick Mochel
2003-06-13  8:41                       ` Alan Cox
2003-06-13 11:00                         ` Paul Mackerras
2003-06-13 11:07                           ` Herbert Xu
2003-06-13 13:31                           ` Alan Cox
2003-06-13 19:57                             ` Joe Korty
2003-06-13 21:10                               ` Alan Cox
2003-06-13 11:17                       ` David Schwartz
2003-06-13 15:44                         ` Davide Libenzi
2003-06-12 23:42                     ` Robert Love
2003-06-12 23:45                     ` Davide Libenzi
2003-06-12 23:05       ` Robert Love
2003-06-19 19:51       ` Werner Almesberger
2003-06-26 12:17         ` Tommi Virtanen
2003-06-26 14:35           ` Werner Almesberger
2003-06-13  8:40     ` Alan Cox
2003-06-13  9:14       ` Olivier Galibert
2003-06-19 20:53         ` Werner Almesberger
2003-06-13 16:05       ` Steven Dake
2003-06-13 16:32       ` Greg KH
2003-06-13 15:51   ` Steven Dake
2003-06-13 16:41     ` Patrick Mochel
2003-06-13 16:42     ` Greg KH
2003-06-13 17:17       ` Chris Friesen
2003-06-12 22:27 ` Oliver Neukum
2003-06-13 16:03   ` Steven Dake
2003-06-13 16:50     ` Patrick Mochel
2003-06-13 17:10       ` Steven Dake
2003-06-13 18:26         ` Greg KH
2003-06-13 19:02         ` Patrick Mansfield
2003-06-13 17:32     ` Oliver Neukum
2003-06-13 18:23     ` Greg KH
2003-06-13 18:24     ` Greg KH
2003-06-13  7:17 ` Christoph Hellwig
2003-06-13 18:06 ` Linus Torvalds
2003-06-19 23:32   ` Werner Almesberger
2003-06-19 23:42     ` Steven Dake
2003-06-20  0:05       ` Linus Torvalds
2003-06-20  0:10         ` Steven Dake
2003-06-20  0:43           ` Linus Torvalds
2003-06-20  2:26             ` Werner Almesberger
2003-06-20 17:03             ` Steven Dake
2003-06-20 17:18               ` Patrick Mochel
2003-06-14  6:36 John Bradford

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=Pine.LNX.4.53.0306130823170.4004@chaos \
    --to=root@chaos.analogic.com \
    --cc=akpm@digeo.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mochel@osdl.org \
    --cc=paulus@samba.org \
    --cc=rml@tech9.net \
    --cc=sdake@mvista.com \
    /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).