Re: WaitForSingleObject() will not deadlock
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Wed, 04 Jul 2007 01:15:31 -0400
Actually, all I found in the Butenhof reference was a quote from Alice in Wonderland, and
the next page is 97, thus skipping everything in between.
Memory ordering (which I would not have thought of as "memory visibility guarantees") is
an ancient topic. The DEC Alpha was a driver writer's nightmare because it had no
guarantees for write orderings, and it took several releases of the chip before they got
smart enough to put a memory fence instruction in. The nightmares this gave driver
writers was substantial, since you couldn't be guaranteed what order data would hit the
control registers, and the trick was to write out N (or N+1, I have thankfully forgotten)
values, thus forcing the value in the write pipe to be flushed. N was initially 4, and
when the next chip came out with a 7-deep write-pipe, every device driver for the Alpha
stopped working correctly.
In addition to the opportunistic scheduling of the write pipe, if a second value was
written to the a given memory address, and that address had a value pending in the write
pipe, the Alpha simply replaced the value in the write pipe without bothering to write the
current value back to memory. You can see what a disaster this was for doing things like
writing to control registers such as a FIFO buffer register!
The x86 architecture explicitly guarantees that data values in the write pipe are written
out "in the order they were generated by the CPU core" (FIFO ordering), and the only issue
then is making sure that there is a memory fence that forces the data out from the write
pipe to memory. The lock prefix forces a memory fence and causes the write pipe to be
flushed to memory. The x64 has explicit SFENCE (Store-fence), LFENCE (Load-fence) and
MFENCE (memory-fence, both store-and-load) instructions.
joe
On Tue, 03 Jul 2007 18:49:15 -0500, "Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote:
On Tue, 03 Jul 2007 17:18:24 -0400, Joseph M. NewcomerJoseph M. Newcomer [MVP]
<newcomer@xxxxxxxxxxxx> wrote:
I agree. It makes no sense, athough the term "memory visibility guarantees" is not
actually defined anywhere I can find; the apparent interpretation that it guarantees that
all memory is consistent seems fundamental to any kind of locking structure. Otherwise,
the locks cannot possibly work.
See "Memory Ordering" here:
http://msdn2.microsoft.com/en-us/library/ms686355.aspx
In "Programming with POSIX Threads", Butenhof devotes a number of pages to
"Memory visibility between threads"; here's a link to page 89 where he
gives four rules POSIX obeys:
http://books.google.com/books?id=_xvnuFzo7q0C&pg=PA88&ots=Kl5R_S-7Y9&dq=%22memory+visibility%22+isbn:0201633922&num=50&sig=2L0dMbDOavxA9VVnDA2Ai28gIF8#PPA89,M1
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Follow-Ups:
- Re: WaitForSingleObject() will not deadlock
- From: Doug Harrison [MVP]
- Re: WaitForSingleObject() will not deadlock
- References:
- Re: WaitForSingleObject() will not deadlock
- From: Joseph M . Newcomer
- Re: WaitForSingleObject() will not deadlock
- From: Frank Cusack
- Re: WaitForSingleObject() will not deadlock
- From: Joseph M . Newcomer
- Re: WaitForSingleObject() will not deadlock
- From: Alexander Grigoriev
- Re: WaitForSingleObject() will not deadlock
- From: Frank Cusack
- Re: WaitForSingleObject() will not deadlock
- From: Alexander Grigoriev
- Re: WaitForSingleObject() will not deadlock
- From: Frank Cusack
- Re: WaitForSingleObject() will not deadlock
- From: Doug Harrison [MVP]
- Re: WaitForSingleObject() will not deadlock
- From: Joseph M . Newcomer
- Re: WaitForSingleObject() will not deadlock
- From: Doug Harrison [MVP]
- Re: WaitForSingleObject() will not deadlock
- Prev by Date: Re: ASSERT in CFile::GetStatus
- Next by Date: Two Icons in Status Bar
- Previous by thread: Re: WaitForSingleObject() will not deadlock
- Next by thread: Re: WaitForSingleObject() will not deadlock
- Index(es):
Relevant Pages
|