"Roshan Naik" <someone@nowhere.com> wrote in message
news:41255327.8D3AEF5E@nowhere.com...
>
> Lets say the threads and locks related abstractions go into the header
> <thread>
> When users tries to #include <thread> in order to instantate threads and
fire
> off multiple threads on a non-MT system, the compiler should preferrable
to indicate a
> clear *compiler error* at compile time rather than at run time. This
should be a
> trivial to do using compile time asserts.... on just not shipping a
<thread> on that
> system
> :-)

If threads are implemented as a library and the actual thread creation has a
similar appearance as a function or member call, the compiler could just
treat the invocation as a normal call. Compiler could offcourse issue a
warning, suppressable by a compiler option, when invocation syntax is used
instead of normal access, on systems without MT support.

- jive


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Roshan Naik wrote:

> Jim Hyslop wrote:
>>Implementing the support is quite trivial, actually. A system that does
>>not support threads generates exactly the code that is required:
>>nothing. It should be easy enough to recognize the MT features and just
>>ignore them. I'd prefer ignoring MT features over generating an error,
>>because with an error you don't have portable code: you have to wrap
>>your code in ugly #ifdefs.
> There are two parts to that ignoring versus compile time errors.
> First the core language features for MT , and second Standard Library
> portions.
>
> Lets say the threads and locks related abstractions go into the header
> <thread>
> When users tries to #include <thread> in order to instantate threads and fire
> off multiple
> threads on a non-MT system, the compiler should preferrable to indicate a
> clear
> *compiler error* at compile time rather than at run time. This should be a
> trivial to do
> using compile time asserts.... on just not shipping a <thread> on that system
> :-)
First let me say that when I wrote the above paragraph, I was thinking
only about the peripheral support for threads, such as locks, mutexes
and other synchronization stuff. I had completely overlooked the actual
_creation_ of threads.

Having realized my oversight, I acknowledge that a compile error is
probably the better choice for some features, because the programmer
will know right away there's a problem.

I don't think the error should be triggered simply by including the
header, though - it should probably be triggered when the programmer
tries to use a MT feature that cannot be ignored.

--
Jim



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Sergey P. Derevyago wrote:
> [...]
>  Sure. C++ standard must _allow_ for concurrent or simultaneous
> execution. That's all.
>  The remaining issues should be addressed by library...

The whole point is that a library cannot determine how the compiler
should or should not rearrange operations that affect concurrent
execution.  So simply saying: "C++ permits concurrent execution of
programs" does *not* constitute necessary support for multithreading.
That's like defining basketball rules by saying: "The ball is permitted
to move about the court.  The remainder of the rules shall be determined
by the acting official."  Well that's fine for defining what is
permissible, but not for defining what is *not* permissible, which
happens to be an important issue in threading.  Sometimes you need to
constrain the compiler more than current rules allow in order to have
successful concurrency.  That is why a library is not a sufficient
solution to MT.

Dave

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Alexander Terekhov" <terekhov@web.de> wrote in message
news:4124C5ED.C403E0C1@web.de...
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf
(Final Draft, August 19, 2004, 10:11am)

Eat carefully. The cake is hot. ;-)

----------------

We need at least that amount of work and that level of precision (and
hopefully less restrictive semantics... we can always learn from their
mistakes) to wed threads with C++.

Andrei


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]