Marcin Dalecki <[EMAIL PROTECTED]> writes:
| On 2005-04-15, at 23:59, Mike Stump wrote:
|
| > On Friday, April 15, 2005, at 02:52 PM, Marcin Dalecki wrote:
| >>> My god, you didn't actually buy into that did you? Hint, it was
| >>> is, and always will be a joke.
| >>
| >> You dare to explain wh
Joe Buck wrote:
On Sun, Apr 24, 2005 at 03:07:05PM -0700, Melissa O'Neill wrote:
I'm in the camp that believes that the committee shouldn't change the
semantics of volatile.
Many good arguments, particularly your point about "old volatile"
vs "new volatile".
I agree.
I've no objection in princip
On Sun, Apr 24, 2005 at 03:07:05PM -0700, Melissa O'Neill wrote:
> I'm in the camp that believes that the committee shouldn't change the
> semantics of volatile.
Many good arguments, particularly your point about "old volatile"
vs "new volatile".
I'm in the camp that believes that the committee shouldn't change the
semantics of volatile. There are three key reasons to my argument:
- "You don't pay for what you don't use"
- Nonthreaded uses of volatile
- Avoiding insidious change
You don't pay for what you don't use
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Paul Koning wrote:
>>> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
>>
Robert> Ken Raeburn wrote:
>> >> That's what I thought. So, unless the compiler (or language
>> spec) >> is going to become thread-aware, any
Paul Koning wrote:
"Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Ken Raeburn wrote:
>> That's what I thought. So, unless the compiler (or language spec)
>> is going to become thread-aware, any data to be shared across
>> threads needs to be declared volatile, even if some other
> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Ken Raeburn wrote:
>> That's what I thought. So, unless the compiler (or language spec)
>> is going to become thread-aware, any data to be shared across
>> threads needs to be declared volatile, even if some other
>> mechanis
Ken Raeburn wrote:
That's what I thought. So, unless the compiler (or language spec) is
going to become thread-aware, any data to be shared across threads needs
to be declared volatile, even if some other mechanism (like a mutex) is
in use to do some synchronization. Which means performance wo
On Apr 18, 2005, at 18:17, Robert Dewar wrote:
Is there anything in the language specifications (mainly C++ in this
context, but is this an area where C and C++ are going to diverge, or
is C likely to follow suit?) that prohibits spurious writes to a
location?
Surely the deal is that spurious wr
On Apr 18, 2005, at 3:08 PM, Ken Raeburn wrote:
Is there anything in the language specifications (mainly C++ in
this context, but is this an area where C and C++ are going to
diverge, or is C likely to follow suit?) that prohibits spurious
writes to a location?
No, in both languages. The rea
Ken Raeburn wrote:
On Apr 16, 2005, at 15:45, Nathan Sidwell wrote:
It's not clear to me which is the best approach. (b) allows threads to
be supported via copious uses of volatile (but probably introduces
pessimizations), whereas (a) forces the thread interactions to be
compiler
visible (but sho
On Apr 16, 2005, at 15:45, Nathan Sidwell wrote:
It's not clear to me which is the best approach. (b) allows threads to
be supported via copious uses of volatile (but probably introduces
pessimizations), whereas (a) forces the thread interactions to be
compiler
visible (but shows more promise for
Jason Merrill <[EMAIL PROTECTED]> writes:
> On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]>
> wrote:
>
> > Jason Merrill wrote:
> >> The C++ committee (well, a subgroup represented at this meeting by Hans
> >> Boehm) is working on a memory model that supports threaded
On Thu, 14 Apr 2005 23:11:03 -0400, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Again, not always. Consider chaotic asynchronous algorithms
> (like variations of simulated annealing). They need no locks nor
> any other kind of synchronization, though sometimes they'll use
> some form of control s
Jason Merrill wrote:
On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
Could you clarify whether 'other writes' means 'other _volatile_ writes',
or '_any_ other writes'? Since non-volatile writes are not visible
outside of the abstract machine, how can they be ordered
Paul Koning wrote:
"Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:
Marcin> On 2005-04-15, at 20:18, Mike Stump wrote:
>> On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote:
>>> Templates are a no-go for a well known and well defined subset
>>> for C++ for embedded programmin
Marcin Dalecki:
>> Don't accept the marketing explanation either.
>
> Agreed. Maybe the idea of a subset of C++ basically coming down what
> would be a C with inheritance
> was somehow over-hyped by too much marketing bragging as an excuse for
> some defective C++ compiler
> implementation at int
On 2005-04-16, at 00:38, Mike Stump wrote:
Seriously, what does that have to do with anything?
Well perhaps my view is somehow shed by the project I'm currently
sitting on.
It's actually kernel programming. And this occurs for me quite to be
quite the kind of
stuff, which may be very well put thi
On Friday, April 15, 2005, at 03:19 PM, Marcin Dalecki wrote:
You can read it as, it was and will always be, just a bad idea.
When will be a full and standard conforming template implementation in
GCC finished then?
?
Seriously, what does that have to do with anything?
I know, let's not recommend
On 2005-04-15, at 23:59, Mike Stump wrote:
On Friday, April 15, 2005, at 02:52 PM, Marcin Dalecki wrote:
My god, you didn't actually buy into that did you? Hint, it was is,
and always will be a joke.
You dare to explain what's so funny about it?
Oh, it wasn't funny. Maybe the English is slightl
> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:
Marcin> On 2005-04-15, at 20:18, Mike Stump wrote:
>> On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote:
>>> Templates are a no-go for a well known and well defined subset
>>> for C++ for embedded programming known comm
On Friday, April 15, 2005, at 02:52 PM, Marcin Dalecki wrote:
My god, you didn't actually buy into that did you? Hint, it was is,
and always will be a joke.
You dare to explain what's so funny about it?
Oh, it wasn't funny. Maybe the English is slightly too idiomatic? I'd
need someone that un
On 2005-04-15, at 19:58, Gabriel Dos Reis wrote:
| Templates are a no-go for a well known and well defined subset for
C++
| for embedded programming known commonly as well embedded C++.
You'd be surprised to learn that embedded systems people do use
templates for various things -- among which, ma
On 2005-04-15, at 20:18, Mike Stump wrote:
On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote:
Templates are a no-go for a well known and well defined subset for C++
for embedded programming known commonly as well embedded C++.
My god, you didn't actually buy into that did you? Hint,
> From: Paul Koning <[EMAIL PROTECTED]>
>> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:
>
>>> Michael N. Moran wrote: I'm very much in favor of fine grained
>>> synchronization primitives in the compiler, but not of changes to
>>> volatile semantics.
>
> Paul> I wonder if it would be su
On Friday, April 15, 2005, at 10:58 AM, Gabriel Dos Reis wrote:
Embedded C++ was a mistake, alas a mistake that seems to last.
No, there are just confused people in the world that think that it is
relevant because they just don't know better, treat the as you'd treat
a person that talks about a
On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote:
Templates are a no-go for a well known and well defined subset for C++
for embedded programming known commonly as well embedded C++.
My god, you didn't actually buy into that did you? Hint, it was is,
and always will be a joke.
Paul Schlie wrote:
Michael N. Moran wrote:
I'm very much in favor of fine grained synchronization primitives
in the compiler, but not of changes to volatile semantics.
I wonder if it would be sufficient (if not preferable) to only extend
(modify) the semantics for heap/stack and const volatile var
Gabriel Dos Reis wrote:
Marcin Dalecki <[EMAIL PROTECTED]> writes:
| Templates are a no-go for a well known and well defined subset for C++
| for embedded programming known commonly as well embedded C++.
You'd be surprised to learn that embedded systems people do use
templates for various things --
Marcin Dalecki <[EMAIL PROTECTED]> writes:
| On 2005-04-15, at 01:10, Richard Henderson wrote:
|
| > On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
| >> Consider Double-Checked Locking
| >> (http://www.cs.umd.edu/~pugh/java/memoryModel/
| >> DoubleCheckedLocking.html).
| >> I used
> "Paul" == Paul Schlie <[EMAIL PROTECTED]> writes:
>> Michael N. Moran wrote: I'm very much in favor of fine grained
>> synchronization primitives in the compiler, but not of changes to
>> volatile semantics.
Paul> I wonder if it would be sufficient (if not preferable) to only
Paul> ext
> Michael N. Moran wrote:
> I'm very much in favor of fine grained synchronization primitives
> in the compiler, but not of changes to volatile semantics.
I wonder if it would be sufficient (if not preferable) to only extend
(modify) the semantics for heap/stack and const volatile variables, as
en
> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:
Marcin> Templates are a no-go for a well known and well defined
Marcin> subset for C++ for embedded programming known commonly as
Marcin> well embedded C++.
I don't think that's a good argument. If people want to emasculate
the la
Jason Merrill wrote:
On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> wrote:
For example, device drivers that perform memory mapped I/O
on memory spaces which are "guarded" and thus need no additional
ordering/synchronization instructions.
You mentioned PowerPC in a previo
Jason Merrill wrote:
The device driver case seems like a more plausible objection to me, but I'd
like to see an example there, too.
Though not widely used, download the OSCL and grep
for volatile.
http://mnmoran.org/oscl-v1.1.tgz
There are many device drivers in this tar-ball, mostly related
to the
On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <[EMAIL PROTECTED]>
wrote:
> Again, I understand the need for ordering/synchronization, I
> simply do not believe that volatile should be overloaded to
> include these semantics.
>
> Part of my point is that there are existing uses of volatil
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| Richard Henderson <[EMAIL PROTECTED]> writes:
|
| | On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
| | > Consider Double-Checked Locking
| | > (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html).
| | > I used DCL
On Thu, 2005-04-14 at 23:33 +0200, Jason Merrill wrote:
> On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar <[EMAIL PROTECTED]> wrote:
> > [Ada standard]
>
> Yep, sounds a lot like C/C++: volatile reads and writes are required to
> have sequential ordering relative to each other, but (outside the c
Richard Henderson <[EMAIL PROTECTED]> writes:
| On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
| > Consider Double-Checked Locking
| > (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html).
| > I used DCL with explicit memory barriers to implement thread-safe
| >
Laurent GUERBY <[EMAIL PROTECTED]> writes:
| I'm including the standard annotations, they have no standard
| value but sometimes do help.
[...]
Thanks!
-- Gaby
On Apr 15, 2005, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
> On 2005-04-15, at 01:10, Richard Henderson wrote:
>> template T acquire(T *ptr);
>> template void release(T *ptr, T val);
>>
>> where the functions do the indirection plus the memory ordering?
> Templates are a no-go for a well known
On Apr 14, 2005, at 8:11 PM, Diego Novillo wrote:
The device driver case seems like a more plausible objection to
me, but I'd
like to see an example there, too.
Perhaps Windows? I'd think Windows is chok full of device
drivers written in C++.
Here in Mac OS X land, many device drivers are writt
On 2005-04-15, at 01:10, Richard Henderson wrote:
On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
Consider Double-Checked Locking
(http://www.cs.umd.edu/~pugh/java/memoryModel/
DoubleCheckedLocking.html).
I used DCL with explicit memory barriers to implement thread-safe
initializati
On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
> I shouldn't have used the term "sequential memory ordering." Nobody is
> suggesting that C++ should enforce sequential consistency between threads.
> But even in the weakest memory models...*especially* in the weakest memory
> model
On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
> Consider Double-Checked Locking
> (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html).
> I used DCL with explicit memory barriers to implement thread-safe
> initialization of function-local statics
> (libstdc++-v3
> "Jason" == Jason Merrill <[EMAIL PROTECTED]> writes:
Jason> On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar
Jason> <[EMAIL PROTECTED]> wrote:
>> [Ada standard]
Jason> Yep, sounds a lot like C/C++: volatile reads and writes are
Jason> required to have sequential ordering relative to ea
I'm including the standard annotations, they have no standard
value but sometimes do help.
Laurent
C.6 Shared Variable Control
Dynamic Semantics
15For an atomic object (including an atomic component) all reads and
updates of the object as a whole are indivisibl
On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar <[EMAIL PROTECTED]> wrote:
> [Ada standard]
Yep, sounds a lot like C/C++: volatile reads and writes are required to
have sequential ordering relative to each other, but (outside the current
thread) they are not ordered relative to non-volatile reads
On Thu, 14 Apr 2005 16:04:33 -0400, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 14, 2005 at 05:40:04PM +0200, Jason Merrill wrote:
>
>> But the memory model for the language must provide semantics that make it
>> possible for threaded programs to be written. Currently, if you want to
>
Gabriel Dos Reis wrote:
Seriously, could you give the Ada standardese even though I'm not
supposed to understand?
-- Gaby
Here is the relevant RM quote
15 For an atomic object (including an atomic component) all reads and
updates of the object as a whole are indivisible.
16 For a volatile objec
On Thu, Apr 14, 2005 at 11:19:19PM +0200, Gabriel Dos Reis wrote:
> Diego Novillo <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Seems to me that if C++ is all of the sudden interested in
> | dictating memory semantics for threaded programs, it should also
> | provide language capabilities for other
Diego Novillo <[EMAIL PROTECTED]> writes:
[...]
| Seems to me that if C++ is all of the sudden interested in
| dictating memory semantics for threaded programs, it should also
| provide language capabilities for other synchronization models
| and for threads (as in Java, though the memory model o
Robert Dewar <[EMAIL PROTECTED]> writes:
| One interesting thing to consider here is how the C++ semantics
| compares with that of pragma Volatile in Ada, which is roughly
| intended to be equivalent to volatile in C.
The suggestion made by Hans is to improve over the existing semantics
in C++ (w
On Thu, Apr 14, 2005 at 05:40:04PM +0200, Jason Merrill wrote:
> But the memory model for the language must provide semantics that make it
> possible for threaded programs to be written. Currently, if you want to
> write a portable pthreads program you need to use a mutex around all uses
> of sha
One interesting thing to consider here is how the C++ semantics
compares with that of pragma Volatile in Ada, which is roughly
intended to be equivalent to volatile in C.
Jason Merrill wrote:
On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
... though I suppose you could argue
that they aren't required to be visible outside the current thread.
This is my interpretation since (to my knowledge) the C++ language
does not generally address t
Jason Merrill wrote:
On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]>
wrote:
Jason Merrill wrote:
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs.
As someone who uses the C++ lang
Paul Koning wrote:
"Michael" == Michael N Moran <[EMAIL PROTECTED]> writes:
Michael> Jason Merrill wrote:
>> One proposed change is to the semantics of volatile.
Michael> I'm not familiar with ia64 barrier instructions, but I *am*
Michael> familiar with PowerPC barrier and synchronization
Mic
On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> Jason Merrill wrote:
>> 7 Accessing an object designated by a volatile lvalue (_basic.lval_),
>> modifying an object, calling a library I/O function, or calling a
>> function that does any of those operati
Jason Merrill wrote:
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs. One
proposed change is to the semantics of volatile. Currently, volatile
semantics are constrained by:
6 The observable behavior of
On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]>
wrote:
> Jason Merrill wrote:
>> The C++ committee (well, a subgroup represented at this meeting by Hans
>> Boehm) is working on a memory model that supports threaded programs.
>
> As someone who uses the C++ language and
> "Michael" == Michael N Moran <[EMAIL PROTECTED]> writes:
Michael> Jason Merrill wrote:
>> One proposed change is to the semantics of volatile.
Michael> Since IANALL, but I believe (as obviously you do) that
Michael> changing the semantics of volatile should be under-taken
Michael> with
"Michael N. Moran" <[EMAIL PROTECTED]> writes:
[...]
| While I'm on my soap-box ...
| I would like to see some sort of alignment qualifiers
| added to the C++ language for those of us that need
| to deal with directly with page/cache alignment
| (for both types and objects.)
We just discuss (aga
Jason Merrill wrote:
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs.
As someone who uses the C++ language and multi-threading
extensively in embedded systems, I have come to the following
belief/opinion.
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs. One
proposed change is to the semantics of volatile. Currently, volatile
semantics are constrained by:
6 The observable behavior of the abstract machin
65 matches
Mail list logo
