"Boehm, Hans" <hans_boehm@hp.com> wrote:
[...]
> 2) If any X86 processor actually did visibly reorder loads
> lots of software would break. Therefore it's not likely to
> happen. The fact that they're still recommending DCL tends
> to confirm this.
Yeah. Well, FYI: <Forward Inline>
-------- Original Message --------
Message-ID: <3ECFADCC.8CDF44A6@web.de>
Date: Sat, 24 May 2003 19:37:16 +0200
From: Alexander Terekhov <terekhov@web.de>
Newsgroups: comp.programming.threads
Subject: Re: Hyper-threading -- is it threading? Or is it just Hype?
References: <AuDxa.19756$W97.506384@weber.videotron.net>
<oprpdfsuk4zexmer@news-server.dc.rr.com> <3EC9F852.E554AA6@web.de>
Alexander Terekhov wrote:
>
> David wrote:
> [...]
> > Dave Solomon
> > Intel Threading Developer Center, Program Manager
>
> Dave, would you please tell your folks to pull off and "fix"
> the following document:
>
>
http://cedar.intel.com/media/pdf/threading/developing_multithreaded_applications.pdf
> (Developing Multithreaded Applications: A Platform Consistent Approach)
>
> <quote>
>
> Advice
>
> Use DCL to avoid ....
<Forward Inline>
Date: Sat, 24 May 2003 19:21:46 +0200
Message-Id: <200305241721.h4OHLkQ12946@mailgate5.cinetic.de>
From: "Alexander Terekhov" <terekhov@web.de>
To: "<snip>, Henry" <<snip>@intel.com>
Subject: Re: Hyper-threading -- is it threading? Or is it just Hype?
"<snip>, Henry" <<snip>@intel.com> schrieb am 23.05.03 17:21:52:
>
> Hello Alexander,
> A colleague, Dave Solomon, forwarded me your comment:
>
> > Dave, would you please tell your folks to pull off and "fix" the
following document:
> > Developing Multithreaded Applications: A Platform Consistent Approach.
>
> I'm putting together an errata for version 1.1 of this document. Please
let me know
> what specifically should be fixed. Thanks.
Please take a look at:
http://groups.google.com/groups?threadm=3ECBD751.8DE8AED5%40web.de
(Subject: Re: scoped static singleton question)
>
> Dave probably mentioned this already, but I would also encourage you to
post your
> comments on Intel's threading forum
(www.intel.com/ids/community/threading).
>
> Best regards,
>
> Henry <snip>
> Intel KAI Software Lab
regards,
alexander.
Sent by: owner-javamemorymodel@cs.umd.edu
To: "'David Holmes'" <dholmes@dltech.com.au>, jmm
<JavaMemoryModel@cs.umd.edu>
cc: "'grant.haab@intel.com'" <grant.haab@intel.com>
Subject: RE: JavaMemoryModel: Memory Model updates in the CLR
Chris Brumme's comments don't look correct to me. His argument is
basically that
1) X86 only allows loads to be reordered.
2) Therefore double checked locking works on X86.
3) Since double checked locking is useful and frequently used, we should
strengthen
the memory model to look like the X86 one.
4) Actual Itanium implementations are strong enough that it works there,
too.
(2) doesn't follow from (1). If you allow arbitrary load reordering, DCL
(double checked locking) is clearly broken, since the load of the
"initialized"
data may occur before the initialization check completes. For the same
reason,
(4) isn't correct in general, even if st instructions are really treated
as st.rel.
(I neither know nor care.) His example may (or may not) work on Itanium.
But if you use a separate initialization flag, it definitely doesn't.
Thus, in my opinion, the change he proposes to the memory model would make
things more, rather than less, confusing.
Whether or not DCL works on X86 is unclear. The Intel documentation David
pointed
out (Developing Multithreaded Applications: A Platform Consistent
Approach) in the
next message recommends it. But it doesn't seem to distinguish between
X86 and
Itanium, and the supplied code is clearly broken on Itanium. It also
definitely
breaks on X86 if the compiler generates speculative loads, which may be
beneficial
to performance. Hence it at least needs a "volatile". (And adding the
"volatile"
to the flag would fix the Itanium code, since volatile implies .rel/.acq
there.)
Assuming the compiler preserves ordering (which it will with enough
"volatile"
declarations, I presume), the Intel X86 spec states:
In single-processor systems:
1. Reads can be carried out speculatively and in any order.
...
In multiple-processor systems:
* Individual processors use the same ordering rules as in a
single-processor system.
...
I read that as saying that loadload ordering is not guaranteed.
However, as Doug has also pointed out, there is a reasonable amount of
evidence that:
1) Current processors do not need any barriers other than in the
store-load case.
(There is some code in the Linux kernel that suggest that IDT WinChips are
an
exception to this. But I don't know whether those were even MP-capable.)
2) If any X86 processor actually did visibly reorder loads lots of
software would break.
Therefore it's not likely to happen. The fact that they're still
recommending DCL tends
to confirm this.
Thus in the absence of compiler reordering DCL probably actually works on
X86, at least
as far as I can tell.
Hans
> -----Original Message-----
> From: David Holmes [mailto:dholmes@dltech.com.au]
> Sent: Monday, May 19, 2003 7:14 PM
> To: jmm
> Subject: JavaMemoryModel: Memory Model updates in the CLR
>
>
> FYI just came across this via some interesting discussions in
> comp.programming.threads:
>
> http://blogs.gotdotnet.com/cbrumme/permalink.aspx/480d3a6d-1aa8-4694-9
> 6db-c69f01d7ff2b
>
>
> David Holmes
>
> -------------------------------
> JavaMemoryModel mailing list -
> http://www.cs.umd.edu/~pugh/java/memoryModel
>
-------------------------------
JavaMemoryModel mailing list -
http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:45 EDT