Threads - When? - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Threads - When?
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

dd.foldhill@googlemail.co
Guest

Posted: Sat Dec 23, 2006 4:42 am Post subject: Threads - When?

How long will it be before c++ has anything to say about threads? Richard Kavanagh -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]

Mathias Gaunard
Guest

Posted: Sat Dec 23, 2006 10:10 am Post subject: Re: Threads - When?

dd.foldhill (AT) googlemail (DOT) com wrote:

Quote:

How long will it be before c++ has anything to say about threads?

2 to 3 years.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Le Chaud Lapin
Guest

Posted: Sat Dec 23, 2006 10:10 am Post subject: Re: Threads - When?

dd.foldhill (AT) googlemail (DOT) com wrote:

Quote:

How long will it be before c++ has anything to say about threads?
Richard Kavanagh

A Very Long Time, hopefully.

I think that it is possible to use C++ as it is effectively in a
multi-threaded environment, provided that good primitives to support
such an environment have been created. In particular, the
synchronization primitives are critical (no pun intended).

I know, for example, that the design of the threading model is not
arbitrary. If one is to write code that is portable and
multi-threaded, there are fundamental principles that are to be
discovered when devising the thread framework, let alone the other
classes like events, mutexes, and semaphores. In other words, simply
wrapping the OS's thread function in a class and "getting on with it"
is not sufficient.

I guess what I am trying to say is that, before C++ is design to
support threads, there remains the task of completing the model of a
thread itself, not at a low-level, but a higher-level, within any
language.

To give two hints:

1. There was a post not long about where a programmer wanted to
manually rollback the stack of another thread, essentially duplicating
what exception handling code would do.

2. There is also the recurring scenario where thread B is in the middle
of a lengthy process and thread A wants it to stop right away, but in a
clean way also.

I believe that both of these problems, if solved elegantly, would force
a fundamental reconsideration of the basic principles underlying thread
usage, and a framework supporting the new model could be implemented
entirely in C++, relatively portably, with no changes to the language.

-Le Chaud Lapin-

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gianni Mariani
Guest

Posted: Sun Dec 24, 2006 1:14 am Post subject: Re: Threads - When?

Le Chaud Lapin wrote:
....

Quote:

I believe that both of these problems, if solved elegantly, would force
a fundamental reconsideration of the basic principles underlying thread
usage, and a framework supporting the new model could be implemented
entirely in C++, relatively portably, with no changes to the language.

Many threaded C++ libraries are available without having solved the
problems you state. While they might be nice to solve, there is a large
problem space that does not need to solve these.

IMHO, the fact that there are so many threaded C++ applications means
that it's sorely missing.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Joe Seigh
Guest

Posted: Sun Dec 24, 2006 1:16 am Post subject: Re: Threads - When?

Le Chaud Lapin wrote:

Quote:

dd.foldhill (AT) googlemail (DOT) com wrote:

How long will it be before c++ has anything to say about threads?
Richard Kavanagh

A Very Long Time, hopefully.

I think that it is possible to use C++ as it is effectively in a
multi-threaded environment, provided that good primitives to support
such an environment have been created. In particular, the
synchronization primitives are critical (no pun intended).

I know, for example, that the design of the threading model is not
arbitrary. If one is to write code that is portable and
multi-threaded, there are fundamental principles that are to be
discovered when devising the thread framework, let alone the other
classes like events, mutexes, and semaphores. In other words, simply
wrapping the OS's thread function in a class and "getting on with it"
is not sufficient.

I guess what I am trying to say is that, before C++ is design to
support threads, there remains the task of completing the model of a
thread itself, not at a low-level, but a higher-level, within any
language.

Unfortunately, they seem to be concentrating on low level design
right now, specifically the memory model. The problem is they
don't know how to do high level specification so they're creating
a low level specification and will do the higher level constructs
in the form of a meta implementation. It turns out that things
like deadlock are actually artifacts of implementation. There's
nothing inherent in locking that requires deadlock to happen. But
if your meta implementation can allow deadlock to occur then all
your actual lock implementations will be required to deadlock
under certain conditions.

There might be a loophole where you could claim if the specification
has non-observable behavior, you could ignore it. But with the fondness
for post condition definitions in C++, they will likely make behavior that
is non-observable in a multi-threaded environment deterministically
observable in a single threaded environment.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Mathias Gaunard
Guest

Posted: Sun Dec 24, 2006 5:02 pm Post subject: Re: Threads - When?

Le Chaud Lapin wrote:

Quote:

I think that it is possible to use C++ as it is effectively in a
multi-threaded environment

The C++ standard doesn't guarantee that C++ is usable in a
multi-threaded environment.

That is what is being corrected.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Le Chaud Lapin
Guest

Posted: Sun Dec 24, 2006 5:03 pm Post subject: Re: Threads - When?

Hi Joe,

Joe Seigh wrote:

Quote:

What do you mean here? Are they concocting new low-level C++
primitives that presume the existence of hardware instructions to
support those new primitives?

Quote:

It turns out that things
like deadlock are actually artifacts of implementation.

Implementation of the programmer's problem?

If so, I agree. Deadlock is an engineering (design) issue. If a
system deadlocks, it deadlocks because the programmer has constructed
the program in a manner in which it should not have been constructed.
The fundamental questions then become:

1. Was there a lack of in C++ or OS primitives that made deadlock
inevitable?

2. Was the use of those primitives improper?

3. Were the primitives present, but in a form that obscures the path to
good system structure?

It has been my experience that, at least on industrial strength
operating systems like Microsoft Windows, the problem is never #1.
Programmers who appreciate their art will learn what they need to know,
so often, the problem is not #2. The problem is most often #3. I
could go to Google right now and do a search on "thread class" and
"C++", and find a bunch of examples of people who have wrapped threads
in classes. I think this is the wrong approach. Wrong because there
is a certain mood that a programmer should when using any framework,
and that mood, IMO, is not achievable by wrapping a thread in a class.
That mood is, however, achievable by wrapping the _other_
synchronization primitives in classes.

IBM has written a series of excellent articles that show how to port
applications to Linux from Windows. Reading these articles helps to
convince oneself that there is a defect in our current expectations of
the thread function, considering many scenarios:
http://www.ibm.com/Search/?q=threading+mutex+Windows&v=14&lang=en&cc=us&en=utf&Search.x=0&Search.y=0&Search=Search

These synchronization primitives do not exist in a form that is
portable, of course, but at least on many industrial strength operating
systems, they are present. The only qualm I with Microsoft's Win32 API
for synchronization is the critical section. It is the only primitive
where it is impossible to wrap it in a truly portable (no #define's)
C++ wrapper facade. It's raw presentation is a Windows-native struct,
as opposed to a HANDLE which is actually a pointer type. All the other
primitives can be made more or less portable.

But again, what I learned by wrapping these primitives is that the
problem with synchronization has nothing to do with defects in C++. It
has to do with how one thinks about concurrent programming. In
particular, to find a regular framework for multi-threading, it helps
to make certain fundamental assumptions about the thread function. An
analogy would be a stack for recursion. One does not really need a
stack to do recursion, but the assumption and expectation that it is
available makes life easier, and no modern programmer would think of
using recursive functions on any other basis.

The same applies to threading. Do we need a breakthrough? No.
Modification in expectations? Yes. For threading to feel natural, we
need to have confidence knowing that complexity will remain constant no
matter how many threads or locked global objects we have. This is a
matter of elegance. Take a look at this link, and imagine having 80 or
so invocations of this function and its friends in one program (as I do
now), and ask yourself if you would feel confident that your code would
not deadlock.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitformultipleobjects.asp

I wouldn't.

Quote:

There's
nothing inherent in locking that requires deadlock to happen. But
if your meta implementation can allow deadlock to occur then all
your actual lock implementations will be required to deadlock
under certain conditions.

What do you mean by this? :)

Quote:

There might be a loophole where you could claim if the specification
has non-observable behavior, you could ignore it. But with the fondness
for post condition definitions in C++, they will likely make behavior that
is non-observable in a multi-threaded environment deterministically
observable in a single threaded environment.

And this?

-Le Chaud Lapin-

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gianni Mariani
Guest

Posted: Sun Dec 24, 2006 5:03 pm Post subject: Re: Threads - When?

Joe Seigh wrote:
....

Quote:

I think I know what you're saying but I don't think many others do.

I hadn't thought about post condition definitions in threaded
environments until just now but you do bring up a very interesting point.

There was one time where a colleague had created a primitive for local
static initialization and I remember he spent some time debugging it
only to find there was no way to test it using post conditions since the
optimal solution, while deterministic, was not testable. The test would
fail after many many hours of "stress testing" but apart from the test
failure there could be no undesirable behaviour. This was somewhat
convoluted and it turned out that the test was invalid. But the point
is, one very experienced and smart programmer can take many hours on an
invalid test, I wonder how much time will be wasted on post-conditions
that become invalid in a threaded environment.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Joe Seigh
Guest

Posted: Wed Dec 27, 2006 11:19 pm Post subject: Re: Threads - When?

Le Chaud Lapin wrote:

Quote:

Hi Joe,

Joe Seigh wrote:

There's
nothing inherent in locking that requires deadlock to happen. But
if your meta implementation can allow deadlock to occur then all
your actual lock implementations will be required to deadlock
under certain conditions.

What do you mean by this? Smile

A meta implementations is one way to specify a design. If your
meta implementation is inherently prone to deadlock, then your
actual implementations must be prone to deadlock as well or else
they're not compliant implementations. Deadlock would be a
required behavior.

Be careful what you ask for. You just might get it.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Mon Jan 01, 2007 2:19 am Post subject: Re: Threads - When?

Le Chaud Lapin wrote:

Quote:

dd.foldhill (AT) googlemail (DOT) com wrote:
How long will it be before c++ has anything to say about threads?

A Very Long Time, hopefully.

In other words, you prefer the current situation, where it is
impossible to use threads at all in portable C++. (Even on the
same system: under Solaris, code written for Sun CC does not
work with g++, and vice versa, even though both use the same
underlying Posix implementation.)

Quote:

I think that it is possible to use C++ as it is effectively in a
multi-threaded environment, provided that good primitives to support
such an environment have been created. In particular, the
synchronization primitives are critical (no pun intended).

You need more than primitives. As long as accessing memory from
two different threads is undefined behavior, you cannot write
multithreaded programs. And the current sequence point model
simply doesn't work in a multithreaded environment.

[...]

Quote:

To give two hints:

1. There was a post not long about where a programmer wanted to
manually rollback the stack of another thread, essentially duplicating
what exception handling code would do.

2. There is also the recurring scenario where thread B is in the middle
of a lengthy process and thread A wants it to stop right away, but in a
clean way also.

I believe that both of these problems, if solved elegantly, would force
a fundamental reconsideration of the basic principles underlying thread
usage, and a framework supporting the new model could be implemented
entirely in C++, relatively portably, with no changes to the language.

C++ has a requirement that it be implementable under current
operating systems. Under current operating systems---at least
under Solaris and Linux, and I think under Windows---there is no
way to implement a general solution to these problems; both
require significant collaboration in the manipulated thread. So
it would be extremely surprising if the C++ standard required a
solution to them. And useless---a standard that cannot be
implemented under Windows or Unix isn't of any interest to
anyone.

--
James Kanze (Gabi Software) email: james.kanze (AT) gmail (DOT) com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Le Chaud Lapin
Guest

Posted: Mon Jan 01, 2007 7:55 am Post subject: Re: Threads - When?

James Kanze wrote:

Quote:

Le Chaud Lapin wrote:

I think that it is possible to use C++ as it is effectively in a
multi-threaded environment, provided that good primitives to support
such an environment have been created. In particular, the
synchronization primitives are critical (no pun intended).

You need more than primitives. As long as accessing memory from
two different threads is undefined behavior, you cannot write
multithreaded programs. And the current sequence point model
simply doesn't work in a multithreaded environment.

It's not undefined in my framework. I use old-fashioned
locking/unlocking.

Quote:

I have Windows and Linux covered meaning that, if you use only the
interfaces of my synchronization primitives (Mutex, Event, etc.) it
will cross compile, but the implementation is not portable of course.
But if you compile the _code_ that uses these primitives, that code is
portable in the strictest sense, meaning, it is not possible to look at
the code and tell which OS is for. This hints that there are actually
two problems:

1. Having available the basic primitives of synchronization
2. Constructing a framework in such way that the use of that framework
does not drive the programmer insane.

These are two separate issues.

The first problem is the domain of the OS people. For example, if
there were no atomic operations like test-and-set, or even an
ALU-managed XOR to external store, there would be nothing the C++
library writer could do to guarantee safeness. Luckily, that's not the
case. We not only have that, we have a lot more. It's just that some
OS vendors have not paid attention to those who have already crossed
the finish line.

Once the first part is done, then the second part can be finished, but
not before.

This is what I said about the OS people doing their part. If such a
framework is to have and minimal standards of elegance, it has to be
pure C++ to start with, the model itself has to make some sense, the
usage pattern has to make some sense, and there cannot be any
unexpected quirkiness because you had to compensate for the lack of a
kernel-mode primitive on a particular OS (like spawning a new thread
just to get a WaitableTimer on Windows CE).

In my experience, despite Win32's bland synchro API, it is wrappable,
and what is surprising is that if you ignore the limitation on number
of handles for WaitForMultipleObjects, and the fact that Windows CE
does not support Waitable Timers, all the primitives to provide closure
for synchronization are present. IBM also did a great job showing that
the same model can be realized on Linux.

The most important thing I think that is coming out of all of this
activity is that the realization that certain primitives are
fundamental, and not really optional, something discovered long ago
with Dijkstra's execution stack as it became generally accepted that an
execution stack is not something he simply dreamed up and thought would
be nice to have, but fundamental.

Also, to remain honest, I did not do critical sections, which means I
use Mutex's exclusively for locking, with performance hit, but that
will fixed. My gut feeling is that Microsoft implemented them using
nothing more than test-and-set with failover to a real mutex on
Windows. I neglected them because it was hard to make something
portable if your C++ class must include in its declaration something
that #include's from Wnidows.h].

So to summarize: The OS people can make the primitives as raw and
unsightly as they want as long as the primitives are present and
complete. From that, it becomes easy to write a clean, C++ wrapper
framework to support robust multi-threading.

-Le Chaud Lapin-

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dilip
Guest

Posted: Wed Jan 03, 2007 1:05 am Post subject: Re: Threads - When?

James Kanze wrote:

Quote:

Le Chaud Lapin wrote:
Also, to remain honest, I did not do critical sections, which means I
use Mutex's exclusively for locking, with performance hit, but that
will fixed.

I presume here that you are confusing the name of the system
request with the actual functionality it provides. I know of no
system today which provides a pure critical section; what
Windows calls a critical section is in fact a mutex.

No. The OP is right in this regard. Critical Sections are a
lightweight mechanism to synchronize access between 2 threads *within*
the same process. Grabbing a critical section is probably an atomic
test-and-set instruction. Mutexes on the other hand, have an
independant existence under windows. However critical sections do have
to drop down to kernel mode if a lock is under contention. If you are
interested you can take a look at this link:
http://msdn.microsoft.com/msdnmag/issues/03/12/CriticalSections/default.aspx
It delves into great depths.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Lourens Veen
Guest

Posted: Thu Jan 04, 2007 1:29 am Post subject: Re: Threads - When?

Le Chaud Lapin wrote:

Quote:

James Kanze wrote:

Or more likely, you're counting on some additional
guarantees from the implementation. Some of those guarantees
are pretty wide spread. Others not. The problem is that even
the widespread ones aren't part of the C++ standard (which
doesn't recognize threads) nor Posix (which doesn't recognize
C++). And not all are well documented, or even really
guaranteed from one release of the compiler to the next.

I do not think C++ should be thread-aware any more than it should be
"device driver" aware. I lose not one second of sleep knowing that,
if I have a multi-threaded application where two threads attack the
same
global variable, there is potential for a race-condition. This is
obvious, and IMO, has nothing to do with C++.

The problem is not whether it will work or not, the problem is that
there is currently no way of writing a (guaranteed) portable C++
programme that uses threads. Currently, anything to do with threads
is undefined behaviour.

The C++ language semantics are specified in terms of an
abstract "virtual machine" to make the language specification
independent of any OS. If we want to implement a threading library,
then we have to specify its semantics in terms of that virtual
machine, just like with the rest of the language. And to be able to
define a mutex and say "No more than one thread shall own a mutex at
the same time", the virtual machine needs to support multithreading.

So, the question is how to extend the C++ virtual machine to support
threads, and do it in a way that keeps it compatible with all the
mainstream operating systems in use today. Only when we have that can
we describe primitives and/or a standard library extension in terms
of it.

Lourens

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dilip
Guest

Posted: Thu Jan 04, 2007 1:30 am Post subject: Re: Threads - When?

{ to mods: I swear this will be my last OT post Smile

}

Rupert Kittinger wrote:

Quote:

Fortunately, it is clear what is meant by "condition_variable" since
they are not available in the Win32 API Smile

Now they are, but only in Vista. See the 2nd point in this post:
http://www.bluebytesoftware.com/blog/PermaLink,guid,17433c64-f45e-40f7-8772-
dedb69ab2190.aspx

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

James Kanze
Guest

Posted: Fri Jan 05, 2007 3:10 am Post subject: Re: Threads - When?

Le Chaud Lapin wrote:

Quote:

Lourens Veen wrote:
The problem is not whether it will work or not, the problem is that
there is currently no way of writing a (guaranteed) portable C++
programme that uses threads. Currently, anything to do with threads
is undefined behaviour.

And IMO, that is the fault of the OS people and library writers, not
the language proper.

If the language says its undefined, no one else can make it
portably defined.

Let's take two simple cases from real life:

G++ (like everyone else, I think) uses objects with static
lifetime in its exception handling. Before 3.0, it used them in
such a way that if two threads raised an exception at the same
time, the exception object was corrupted. Please explain how
this is the fault of the OS people and library writers.

Also g++ pre-3.0: every constructor of std::string modified
(incremented, and often later decremented) a single global
counter object. You don't really expect users to use an
explicit lock everytime they construct a string, do you? Of
course, you might consider this a library issue, and not a
language issue, but std::string is defined in the C++ standard,
as part of the language.

Quote:

The C++ language semantics are specified in terms of an
abstract "virtual machine" to make the language specification
independent of any OS. If we want to implement a threading library,
then we have to specify its semantics in terms of that virtual
machine, just like with the rest of the language. And to be able to
define a mutex and say "No more than one thread shall own a mutex at
the same time", the virtual machine needs to support multithreading.

I would agree with this point of view under one condition: absolutely
no changes to C++ would be made.

But adding such statements would be a change. In fact, analysis
has shown that the sequence point model doesn't adapt at all to
a multithreaded context. So a major part of the definition of
expression semantics, and what is or is not conforming, will
change.

Quote:

Note that I am not requesting that no
changes to C++ be made, I am trying to prove a point, which is...

Threading is an OS issue, not a language issue.

Threading is an issue at all levels. The OS can provide the
best primitives in the world, but if your code misuses them,
it's all for naught. At the lowest level, threading is a
hardware issue---if hardware does speculative loads, and pushes
loads forward (as modern hardware does), and doesn't provide the
necessary fence or membar instructions to inhibite this behavior
on command, there's no way an OS can offer the necessary
primitives. But of course, the OS has to play its part; you
don't want to have to implement all of the primitives in each
application, and typically, you probably can't, because some
things will require privileged mode. After that, the compiler
has to ensure that these primitives are actually available to
you, and that it doesn't automatically do anything forbidden in
the generated code. Intel processors have very few registers,
and so often have to spill in complex expressions. If the
compiler spills to static memory, it doesn't matter what the
processor and the OS offers. And of course, having a *standard*
interface, defined in the standard library, certainly helps
portability.

None of which, of course, means that the programmer can ignore
the issues, and not pay attention to threads. All it means is
that when I write a program, I only have to analyse its thread
safety once, against the standard guarantees, rather than for
each platform, against the guarantees given by that platform.

[...]

Quote:

I get the feeling that C++ programmers are, perhaps, expecting some new
keywords to be added to the language to make threading easier, or
whatever.

From where do you get this feeling? My impression is just the
opposite, that there is an enormous resistance to adding any new

keywords for threading; that no one wants any new keywords for
thread support.

--
James Kanze (GABI Software) email:james.kanze (AT) gmail (DOT) com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum