|
Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
Trip Report: Ad-Hoc Meeting on Threads in C++
October 17, 2006 1:15 PM
|
|
The C++ standardization committee is hard at work standardizing threads for the next version of C++. Some members recently met to discuss the issues, and The C++ Source was there. Read on to learn what the world’s leading experts on concurrency are planning for C++0x.
http://www.artima.com/cppsource/threads_meeting.html What is your opinion about the threading standardization issues discussed in this article? |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 2:00 AM
|
|
I really do not understand their complicated way of thinking. Why don't they simply specify a simple library with the following classes:
-thread -critical_section -mutex -semaphore -wait_condition -lock< T> (for RAII) That's all that is needed. The rest of considerations (for example, order of optimizations etc), while not irrelevant, are very excuisite. For example, whoever wants to have atomic bitfield manipulation can always use a critical section to lock a data structure. Furthermore, there is no need to extend the language with new keywords. Finally, it seems really strange that they are going to put threads in the language but no garbage collection. We can live without threads (all it takes is a few lines of code to wrap the native primitives into C++ classes) but it is really difficult to write a collector without compiler support. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 4:57 AM
|
|
Thanks for the article! While the C++ standardization committee truly believes their work is open, in practice very little ever gets to the rest of us.
One thing I don't understand is the reluctance for introducing new keywords to the language. Frankly, i like Lawrence Crowl's proposal best - not because of compatibility with C, but because it is clean and simple. Are new keywords hard for compiler vendors? |
|
Posts: 12 / Nickname: ericne / Registered: February 18, 2005 5:31 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 7:18 AM
|
|
Nemanja.
One of the big reasons why the committee avoids adding new keywords is the fact that it can potentially break source code. Imagine the chaos that would ensue if "fork" were taken to be a keyword. Every program that uses the identifier "fork" would stop compiling. So we couldn't use "fork", we might have to use "__fork" or "_Fork" something ugly like that. Sometimes you can't get by without a new keyword, and several new ones ("static_assert", "concept") are proposed for C++0x. But when a viable library solution exists, it's a safer bet. -- Eric Niebler |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 7:50 AM
|
|
> Imagine the chaos that would ensue if "fork" were
> taken to be a keyword. Every program that uses the > identifier "fork" would stop compiling. Eric, Thanks for answering. It may be just my ignorance, but it should be possible to add context-sensitive keywords, like in C++/CLI: http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx Therefore, fork would be a keyword only within a certain context, like (form your article): int join pending = fork work1( argument ); Am I missing something? Again, I my knowledge of compiler internals is all but non-existing and I appologize if I am suggesting something utterly stupid. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 7:54 AM
|
|
Also, I appologize for the horrible spelling. This forum doesn't seem to have an "Edit" option.
|
|
Posts: 12 / Nickname: ericne / Registered: February 18, 2005 5:31 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 2:47 PM
|
|
Nemanja,
It's not a dumb question at all to wonder if the keywords Lawrence suggested can be made context sensitive. I don't honestly know the answer, although the fact that the "fork" and "join" could show up an arbitrary expressions leads me to think it would be difficult if not impossible. But here's something else to think about. Microsoft added context-sensitive keywords to their language, because they only had to add them to one compiler: theirs. The committee would have to consider all compilers out there when evaluating the feasibily of adding such a feature. -- Eric Niebler |
|
Posts: 1 / Nickname: jwalton / Registered: October 31, 2006 1:59 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 31, 2006 10:47 AM
|
|
> The logical place to signal that something went
> wrong is when joining the terminated thread. I'm not at all sure that I agree with that. It seems to me that the best place to deal with an exception would be within the thread itself (within function_that_throws() for example). I think it would be better to prohibit thread entry functions from throwing altogether (as Java does), or else just terminate the entire application if an uncaught exception escapes the top stack frame of a given thread. Passing the Exception back through join() seems needlessly complicated, and seems to needlessly complicate programs which use threads. What if join() is called after the thread terminates? This implies that we need the ability to "save" the exception until join() is called. What if join() is never called? Would the saved exception just be quietly lost? The Thread which threw the exception obviously didn't deal with it, so this implies we will likely leak some memory (at a minimum, the Thread object itself, in which our saved Exception is presumably stored). I think I would prefer to know what of my Threads had just met an untimely demise than to have it quietly depart, without the necessity for me to figure out a way to call "join()" on each and every Thread I create. I suspect with such a scheme, common practice would be to do something such as: in every single thread, which obviates the need for this complex exception passing scheme. Alternatively, you would have to write some sort of "thread manager", which kept references to all the threads in your system, continuously calling "isRunning()" to monitor each of them, and then calling "join()" to reap exceptions and free the memory associated with each thread. This hardly sounds like something I want to write in every program I ever write. Actually, perhaps the best solution would be to let the user decide what is to be done. Again, to borrow slightly from Java; Associate with each thread an "ExceptionHandler" method or class, which specifies the behavior the Thread should exhibit, with a default which does something pleasantly terminal, such as killing the entire application, or which prints an error to stderr and then kills the Thread. |
|
Posts: 12 / Nickname: wkaras / Registered: December 22, 2003 2:53 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 10:23 AM
|
|
I suggest adding these definitions in the std namespace:
// Use dummy classes to identify sequences. class default_template { }; // PT is any primitive type. void observable_read< PT, class sequence = default_sequence>( PT &x); void observable_write< PT, class sequence = default_sequence>( const PT &x); Sequences in different threads would be distinct even if they had the same name. A valid program execution would be one where the resulting order of observable reads/writes in each sequence would be both valid (as defined by sequence points) for the containing thread, as well as being a "sub-order" (sub-sequence) of the execution's resulting global order of observable reads/writes. (Note that this allows a C++ implementation to ignore the distinction between different sequences in a particular thread.) In practice, these "functions" could be used for communication via memory outside the program. If now or in the future there is such a thing as "inter-thread optimization", it might be necessary to have a distinct method of outside communication in memory. I thought it best that a sequence identifier be something that doesn't bind to any address. Could have used const int, but then the programmer has the tedious job of keeping them distinct over the whole program load. |
|
Posts: 12 / Nickname: wkaras / Registered: December 22, 2003 2:53 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 11:11 AM
|
|
To avoid a need for multi-access bus locking,
observable reads/writes in different sequences should (in general) be allowed to be nominally simultatanous. If an observable write and an observable read or write of the same variable of a primitive type occurred simultaneously in different sequences, the resulting value in of the variable in the both threads is undefined. Each implementation would need to provide a type named std::atomic. Simultaneous observable reads/writes of an atomic instance would have to give correct results for some arbitary ordering of the reads/writes. References to std::atomic must convert implicitly to references of some integral type (that is to say, atomic is equivalent to some intergral type except perhaps with more strict alignment requirements). |
|
Posts: 12 / Nickname: wkaras / Registered: December 22, 2003 2:53 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
November 1, 2006 10:33 AM
|
|
My concern about the memory model proposal describe in the article is that instances need to have a special type in order to be sharable between threads. The sharing of volatile instances between threads (when done correctly) is highly portable to many C++ implementations already. But it isn't practical (for many reasons) to have a volatile STL map shared by multiple threads (protected by a mutex). It seems to me that the discussed memory model would have this issue as well.
This is why I think sharing mechanisms based primarily on special operations rather than special types is a better direction. My hope is that this would make sharable STL containers easy: member function templates to do "first_read" and "last_write" could be added to the Allocator interface. They would be noops for the default allocator. For the "sharing-enabled allocator" they would (respectively) force a non-reordable read from/write to common memory, using the standard-defined special operations. |
|
Posts: 12 / Nickname: ericne / Registered: February 18, 2005 5:31 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 7:10 AM
|
|
Achilleas,
Please Google "Boehm "Threads Cannot Be Implemented As A Library"". In that paper, Hans describes in detail why we can't just standardize thread and lock classes and call it good. For those classes to actually work across platforms, they need to be able to rely on things that the language currently doesn't guarantee. Standardizing C++'s memory model is the first and most important step towards standardizing threads in C++. -- Eric Niebler |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 2:00 AM
|
|
> Achilleas,
> > Please Google "Boehm "Threads Cannot Be Implemented As A > Library"". In that paper, Hans describes in detail why we > can't just standardize thread and lock classes and call it > good. For those classes to actually work across platforms, > they need to be able to rely on things that the language > currently doesn't guarantee. Standardizing C++'s memory > model is the first and most important step towards > standardizing threads in C++. > > -- > Eric Niebler But almost all C++ versions in almost all O/Ses provide threads, critical sections, mutexes and semaphores. Therefore I do not see where is the problem for the 99% of the cases. I am not saying that what Boehm says is not true. What I am saying is that the delay to cater for very excuisite needs (like atomic access to primitives or bitfields) is seriously hurting C++'s image, (again, like with garbage collection) and prevents people from chosing it as a development language, thus hurting its development even more. Of course in the grand scheme of things, it does not really matter, does it? there are plenty of other languages around... |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 4:53 AM
|
|
> But almost all C++ versions in almost all O/Ses provide
> threads, critical sections, mutexes and semaphores. > Therefore I do not see where is the problem for the 99% of > the cases. But how do you port such code or write portable applications? The current answer seems to be that portability is restricted to the set of operating systems sufficiently like that on which it was first written. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 4:05 AM
|
|
> > But almost all C++ versions in almost all O/Ses provide
> > threads, critical sections, mutexes and semaphores. > > Therefore I do not see where is the problem for the 99% > of > > the cases. > > But how do you port such code or write portable > applications? The current answer seems to be that > portability is restricted to the set of operating systems > sufficiently like that on which it was first written. All that is needed is 100% source-code level compatibility. The underlying code shall be different, as it is today for STL's files. |
|
Posts: 12 / Nickname: wkaras / Registered: December 22, 2003 2:53 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
November 2, 2006 1:09 PM
|
|
> But almost all C++ versions in almost all O/Ses provide
> threads, critical sections, mutexes and semaphores. > Therefore I do not see where is the problem for the 99% of > the cases. Most if not all C++ compilers are unable to do optimizations that go beyond the scope of a single source file. This means the compiler has to generate code to write out all (changed) register-mapped variables before calling an external function, and the compiler has to re-load from memory all variables after calling an external function. It's also generally true that external functions are called to take and realease whatever type of mutex is protecting access to shared data structures. I've been told that, on x86 processors this combination is enough to be safe. This is because the actual order of loads and stores is always the same as the order in which the load/store instructions were executed. But on other processors (MIPS, PowerPC, SPARC I think) loads and stores may not happen in the order of execution (as long as accesses of the same location are not reordered). Special instructions need to be added to prevent load/store reordering. Of course, this is only necessary when the threads are running on different CPU cores. I think the urgency with the new memory model is the possibility that multi-core processors may become the norm way before C++1x. And I've already seen one linker that appeared to do some tweaking of the object code. |
|
Posts: 1 / Nickname: ramey / Registered: November 27, 2006 3:32 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
November 27, 2006 9:34 AM
|
|
Eric - thank for a very well written and useful article.
Robert Ramey |
|
Posts: 5 / Nickname: david21001 / Registered: March 26, 2007 6:19 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
March 26, 2007 11:31 AM
|
|
I noticed that Dr. Stroustrup was not in on this discussion.
Any reason why he wasn't included, and there was a Microsoft person. My concern is that Microsoft intentionally does things different than the standard BSD/UNIX/Linux C/C++ community. If Microsoft adopted standard C/C++ conventions there would be no need for many of the preprocessor directives. I would be interested to know the opinions of Dr. Stroustrup on this subject, before the "committee" tinkers with what already is in place. Kind regards, |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 10:49 AM
|
|
This first thing I thought of when reading about this was "Why do they want to turn C++ into Java?"
It doesn't seem to me that language-based threading has been effective enough in any language to recommend it to C++. Rather than trying to paper-over the differences between OS threading models with a one-size-fits-all model, C++ programs address threading at the OS level and end up with more efficient threading without the leaky abstraction surprises that are common with threads-as-objects schemes. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 0:34 PM
|
|
> This first thing I thought of when reading about this was
> "Why do they want to turn C++ into Java?" Possibly because threading works very well in Java (in my opinion). > OS threading models with a one-size-fits-all model, C++ > programs address threading at the OS level and end up with > more efficient threading without the leaky abstraction Java threading can be more efficient than you can easily achieve in C++. For example the implementation of the synchronization primitives depends on how many CPUs are present at RUN TIME. The performance is much better than straight forward use of the Windows critical section methods. |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 2:06 PM
|
|
> Java threading can be more efficient than you can easily
> achieve in C++. For example the implementation of the > synchronization primitives depends on how many CPUs are > present at RUN TIME. The performance is much better than > straight forward use of the Windows critical section > methods. The Windows critical section is the most limited of its synchronization primitives in that it is only useful within a single process. The other primitives are kernel objects and work just fine with multiple CPUs. I don't know enough about Windows internals to know what kind of optimization they do, but I would certainly be skeptical of the idea that Java does it more efficiently. Any measurements to back that up? The main problem with Java is that the threading behavior of a program isn't necessarily consistent across OS's. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 0:21 AM
|
|
> > Java threading can be more efficient than you can
> easily > > achieve in C++. For example the implementation of the > > synchronization primitives depends on how many CPUs are > > present at RUN TIME. The performance is much better > than > > straight forward use of the Windows critical section > > methods. > > The Windows critical section is the most limited of its > synchronization primitives in that it is only useful > within a single process. True, but it is also the fastest and in the context of threading, in process synchronization is what is required. > optimization they do, but I would certainly be skeptical > of the idea that Java does it more efficiently. Any What Java does is use CPU atomic operations (inlined code) to test if a lock is contended, if not contended it can proceed into the critical section without executing any call to the OS. If the lock is contended then it uses the usual OS provided method to block. As most locking is usually uncontended this saves a lot of OS calls and locking is reduced to a minimal test and swap (or similar) instruction. You can (and I have) do something similar in C++, except that you can't inline code which is depends on the number of CPU (I suppose you could generate multiple .dll's etc for the 1 and >1 cases). I tested this ages ago (even the early Microsoft JVM used these techniques), I'm not sure if I can still dig up the code/results. The latest JVM use a lot more optimisation techniques to reduce the cost of locking. |
|
Posts: 12 / Nickname: ericne / Registered: February 18, 2005 5:31 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 2:38 PM
|
|
Nobody is trying to "turn C++ into Java." The committee is interested in standardizing existing practice. We should standardize threads for the simple reason that lots of people are writing multi-threaded C++ programs today. To not put threads in the standard would be to ingore the needs of real C++ programmers.
-- Eric Niebler |
|
Posts: 48 / Nickname: bjarne / Registered: October 17, 2003 3:32 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 29, 2006 7:51 AM
|
|
> Nobody is trying to "turn C++ into Java." The committee is
> interested in standardizing existing practice. We should > standardize threads for the simple reason that lots of > people are writing multi-threaded C++ programs today. To > not put threads in the standard would be to ingore the > needs of real C++ programmers. I picked this message to reply to more or less randomly. I just wanted to thank Eric on a most useful piece of reporting. All too often people ignore the standards process, only to loudly complain when the result doesn't meet their needs - or they think the standard doesn't meet their needs. The committee consists of volunteers - often very dedicated and hard-working volunteers, who devote significant time to explain what's going on and to make information available (Can you search for "WG21" on the web? If you do, you'll find all the proposals - more than you even wanted to know). The C++0x effort are trying to address what many experienced people see as the key problems for the C++ community. It is trying to address them responsibly, with very few resources (i.e. people, money, and time), and in a timely manner. Doing all three is *hard*. See my papers on the direction of C++ (on my publications page: http://www.research.att.com/~bs/papers.html). It is now pretty certain that C++0x will (1) address the serious issues about machine model raised by modern hardware - the standard will address these issues exactly so that "the average programmer" will not have to understand these issues - the language will (at the user level) present a reasonable model of the machine. (2) provide a reasonably simple, portable, and conventional model of threading. It may provide "futures" as a mechanism to save many users from explicit locking. I wish it would also provide some form of message queues, but that is almost certainly not going to happen in this time frame. The committee uses Technical Reports (TRs) to address issues beyong the C++0x timeframe. Threading is a pretty awful way of dealing with concurrency, but it is so widely used that C++0x must address the issue. Purely library-based approaches can't handle real concurrency (e.g., as presented by multi-cores), so there will be some code language support (e.g. for thread local storage and initialization). (3) Programmer-controlled garbage collection, as first suggested by me in 1994 or so, primarily based on the work on Hans Boehm (available open source and and used industrially with C++ for about 15 years now). If you don't like it, you turn it off (actually, the default is "off", so it's more correct to say "if you want it, you turn it on"). (4) Lots more. More than I can mention here - again see my publications page, "WG21", and my C++ page. -- Bjarne Stroustrup: http://www.research.att.com/~bs PS. Try to read Eric's article (again) and other articles. See what's actually written and proposed, rather than just imagining. And please do remember that you couldn't possible get all you could wish for. |
|
Posts: 12 / Nickname: wkaras / Registered: December 22, 2003 2:53 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 31, 2006 9:19 AM
|
|
...
> And please do remember that you couldn't > possible get all you could wish for. That is one of the big advantages of C++ -- if the standard libs don't do what you want, the low- level capabilities are there to implement precisely (and often portably and efficiently) what you do want. So, for me, the key questions about threading/concurrency-enabled memory models are low-level, like "can I implement Lamport's Bakery Algorithm portably for multiple cores?". |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 3:37 PM
|
|
> Nobody is trying to "turn C++ into Java." The committee is
> interested in standardizing existing practice. We should > standardize threads for the simple reason that lots of > people are writing multi-threaded C++ programs today. To > not put threads in the standard would be to ingore the > needs of real C++ programmers. Standardizing existing practice is fine. The problem is that existing practice is platform-specific due to the significant differences between OS implementations of threading. |
|
Posts: 12 / Nickname: ericne / Registered: February 18, 2005 5:31 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 3:52 PM
|
|
> Standardizing existing practice is fine. The problem
> is that existing practice is platform-specific due to > the significant differences between OS implementations > of threading. And that's exactly why we need a standard -- so that nobody has to write platform-specific code if they don't want to. This goes beyond a particular OS's implementation of threading, and right down to the hardware. Consider that an OS like Linux which runs on multiple platforms must "paper over" the hardware differences in order to present a coherent threading API. This is handled by a hardware abstraction layer. We're essentially doing the same thing, except that "papering over" actually consists of finding the core primitive operations supported by all modern computer hardware -- operations like atomic memory access, barriers and fences. Taken together, they define an abstract machine (not to be confused with a VM in the Java sense). Now, we define the semantics of C++ in terms of this abstract machine, and we have a sound basis on which to build multi-threaded C++ applications that are efficient and cross-platform. -- Eric Niebler |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 4:15 PM
|
|
> This goes beyond a particular OS's implementation of
> threading, and right down to the hardware. Perhaps I missing something, but wouldn't implementing threading at the hardware level rather than through the OS have the potential to bring the OS crashing down? How can two entities be manipulating the same hardware registers to different ends? |
|
Posts: 12 / Nickname: ericne / Registered: February 18, 2005 5:31 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 4:41 PM
|
|
> > This goes beyond a particular OS's implementation of
> > threading, and right down to the hardware. > Perhaps I missing something, but wouldn't implementing > threading at the hardware level rather than through the > OS have the potential to bring the OS crashing down? How > can two entities be manipulating the same hardware > registers to different ends? I didn't say we're "implementing threading at the hardware level." I said we're defining the semantics of C++ in terms of an abstract machine. How it's actually implemented is a problem for the compiler and OS vendors. It will work much like it does today, with the exception that the C++ standard will actually make some guarantees for correctly written multi-threaded C++ programs. -- Eric Niebler |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 5:37 PM
|
|
> I didn't say we're "implementing threading at the hardware
> level." You said "right down to the hardware" which certainly implies "implementing threading at the hardware level." > How it's actually > implemented is a problem for the compiler and OS > vendors. It will work much like it does today, with the > exception that the C++ standard will actually make some > guarantees for correctly written multi-threaded C++ > programs. So we're really back to my original point: This will be an abstraction that hides the unique threading characteristics of each OS. This is the same problem that Java attempted to solve (although using a different approach) with mixed results. |
|
Posts: 8 / Nickname: alexstojan / Registered: June 20, 2005 0:51 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 6:25 PM
|
|
> So we're really back to my original point: This will be an
> abstraction that hides the unique threading > characteristics of each OS. > > This is the same problem that Java attempted to solve > (although using a different approach) with mixed results. If I understood Eric correctly, the compiler will be able to use these OS-specific threading characteristics, but the programmer will manipulate threads at the C++ level. So if you say something like atomic<int> x; ... y = x; ... the compiler will "know" the unique threading characteristics of the underlying OS and will generate appropriate (and hopefully optimal) code for this. |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 18, 2006 7:17 PM
|
|
> If I understood Eric correctly, the compiler will be able
> to use these OS-specific threading characteristics, but > the programmer will manipulate threads at the C++ level. > So if you say something like > > atomic<int> x; > ... > y = x; > ... > > the compiler will "know" the unique threading > characteristics of the underlying OS and will generate > appropriate (and hopefully optimal) code for this. I understand, but the core problem isn't converting from a C++ form to an OS call, but that in some cases the C++ application code will not have the same behavior when running on different OS's. There's not a true one-to-one mapping of behavior between threading function implementations on different OS's. That means that an abstraction must either be limited to a common set of functions that behave identically on all systems (assuming that set isn't empty), a broader set with platform-dependent behavior, or a mix of the two. One example: some operating systems use cooperative multithreading exclusively, some use preemptive multithreading exclusively and some use a combination. If you write code with a "sleep" function or "synchronization" function what is the common behavior you expect to see? |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 0:34 AM
|
|
> I understand, but the core problem isn't converting from a
> C++ form to an OS call, but that in some cases the C++ > application code will not have the same behavior when > running on different OS's. As well as the threading methods/classes you also require a set of rules which specify what you can assume and what you can't assume about threading behaviour. If your application sticks to the rules (and does not for example assume that thread scheduling is 'fair') then it will work correctly on any conforming implementation. What frequently goes wrong with threading in Java is that people assume that all systems behave like their own even though the documentation explicitly says that you can't make such an assumption. So the effort is not to guarantee identical behaviour for all code on all systems, but only to guarantee that code which respects the rules (the Memory Model) will work correctly on all systems. Bad code might work on some systems but not on others, but there is nothing new in that. |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 7:15 AM
|
|
> As well as the threading methods/classes you also require
> a set of rules which specify what you can assume and what > you can't assume about threading behaviour. If your > application sticks to the rules (and does not for example > assume that thread scheduling is 'fair') then it will work > correctly on any conforming implementation. But these rules are often more restrictive, make writing threaded code more complicated, and have a higher potential for error than native methods. It's more of a step backward than forward. >Bad code might work on some > systems but not on others, but there is nothing new in > that. A better way to say it is that good code on one system can be bad on another, but I think there is something new about this behavior for C++. What other standard C++ functions behave significantly different on different OS's and require special rules to follow? |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 7:44 AM
|
|
> But these rules are often more restrictive, make writing
> threaded code more complicated, and have a higher > potential for error than native methods. It's more of a > step backward than forward. I suppose it depends on whether you want to be a C++ programmer or a <OS of choice> C++ programmer or (even worse) <OS> <processor> C++ programmer. Or how about just a single processor X86 Windows C++ programmer. It is much easier to develop for multiple targets if you have a common, albeit more restrictive, set of design rules. Do you know how the different memory models supported by various versions of SPARC behave? I gather that some of these are rarely used because although allowing greater performance they break assumptions used by too many applications. |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 7:54 AM
|
|
> I suppose it depends on whether you want to be a C++
> programmer or a <OS of choice> C++ programmer or (even > worse) <OS> <processor> C++ programmer. Or how about just > a single processor X86 Windows C++ programmer. > It is much easier to develop for multiple targets if you > have a common, albeit more restrictive, set of design > rules. I am a programmer that solves real problems. I'm not interested in labels. |
|
Posts: 28 / Nickname: greggwon / Registered: April 6, 2003 1:36 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
November 17, 2006 5:36 AM
|
|
> > This goes beyond a particular OS's implementation of
> > threading, and right down to the hardware. > > Perhaps I missing something, but wouldn't implementing > threading at the hardware level rather than through the OS > have the potential to bring the OS crashing down? How can > two entities be manipulating the same hardware registers > to different ends? I think that a virtual abstraction of threading with no particular hardware or OS as its target provides the best opportunity for portability. The more features you demand at the virtual layer, the harder it is to port and the more dependent on certain behaviors an application can become. This is where languages like java run circles around native languages in portability. As soon as you add threading though, you have to have a memory model that dictates exactly how concurrency is mediated by the language. Otherwise portability goes right out the window and your back to defining 30 macros that represent the hardware requirements for cache synchronization, spin locks, OS locks etc. And suddenly things get ugly. |
|
Posts: 5 / Nickname: david21001 / Registered: March 26, 2007 6:19 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
March 26, 2007 11:41 AM
|
|
we already have a common api; it's called POSIX threads
|
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 2:13 AM
|
|
> Nobody is trying to "turn C++ into Java." The committee is
> interested in standardizing existing practice. We should > standardize threads for the simple reason that lots of > people are writing multi-threaded C++ programs today. To > not put threads in the standard would be to ingore the > needs of real C++ programmers. > > -- > Eric Niebler And not putting garbage collection in the standard is not ignoring the needs of real C++ programmers? I am sorry to say this, but it seems kind of hypocritical. Many C++ programs suffer from manual memory management, and gc is a priority over threads. I have not used a single C++ application that has not crashed in one way or another, due to some wild pointer or memory leak. And using another language is simply not an option: there is no way to write programs like Firefox, Word, Powerpoint and Visio in languages other than C++, because those other languages do not allow the performance of C++. Using multithreading currently is very easy, even if there is not a single wrapper library around: hacking together a few classes to wrap the native calls is very very easy. On the other hand, writing a proper garbage collector is impossible (and don't mention Boehm's collector, because a) it is very under-performant(without type information), b) it does not have weak pointers and other facilities). |
|
Posts: 8 / Nickname: alexstojan / Registered: June 20, 2005 0:51 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 6:34 AM
|
|
> Many C++ programs suffer from manual memory management,
> and gc is a priority over threads. I have not used a > single C++ application that has not crashed in one way or > another, due to some wild pointer or memory leak. Using boost::shared_ptr (or some other kinds of smart pointers) can eliminate many (in some cases all) memory leaks. See boost.org for examples. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 6:56 AM
|
|
> Using boost::shared_ptr (or some other kinds of smart
> pointers) can eliminate many (in some cases all) memory > leaks. See boost.org for examples. In some other cases it eliminates very few leaks. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 4:10 AM
|
|
> > Many C++ programs suffer from manual memory management,
> > and gc is a priority over threads. I have not used a > > single C++ application that has not crashed in one way > or > > another, due to some wild pointer or memory leak. > > Using boost::shared_ptr (or some other kinds of smart > pointers) can eliminate many (in some cases all) memory > leaks. See boost.org for examples. Shared pointers are not enough when there are circular references...which practically rules out lots of useful code. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 7:24 AM
|
|
> And not putting garbage collection in the standard is not
> ignoring the needs of real C++ programmers? > No, it is not :) Seriously, none of developers I know would ever use GC with C++. If you need GC, use a GC enabled language - some of them claim to be very performant, ie D, OCaml... IMHO, for the C++ community threading is much more important issue than GC. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 7:46 AM
|
|
> Seriously, none of developers I know would ever use GC
> with C++. The perils of the self selecting survey! Those developers that desperately needed GC have mostly gone elsewhere. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 8:03 AM
|
|
> > Seriously, none of developers I know would ever use GC
> > with C++. > > The perils of the self selecting survey! Those developers > that desperately needed GC have mostly gone elsewhere. :) Note that I say "would never use GC with C++". Many developers use more than one programming language even within a single project. For the pieces where a GC is beneficial, they just use a lanuage that supports GC. C++ simply cannot become a "GC language", or at least not a good GC language at this point. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 4:14 AM
|
|
> > > Seriously, none of developers I know would ever use
> GC > > > with C++. > > > > The perils of the self selecting survey! Those > developers > > that desperately needed GC have mostly gone elsewhere. > > :) > > Note that I say "would never use GC with C++". Many > developers use more than one programming language even > within a single project. For the pieces where a GC is > beneficial, they just use a lanuage that supports GC. C++ > simply cannot become a "GC language", or at least not a > good GC language at this point. If C++ can not become a good GC language, then how come the Stroustrup, Boehm and others propose the Boehm GC library for serious development? What is happening is that the C++ standard commitee thinks they know better and they are in love with the manual memory management model. There is no real technical reason why C++ can not have garbage collection. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 4:11 AM
|
|
> > And not putting garbage collection in the standard is
> not > > ignoring the needs of real C++ programmers? > > > > No, it is not :) > > Seriously, none of developers I know would ever use GC > with C++. If you need GC, use a GC enabled language - some > of them claim to be very performant, ie D, OCaml... > > IMHO, for the C++ community threading is much more > important issue than GC. I am sorry but any comment that starts with "none of the stuff I know off" can not be taken seriously. IMHO, for the C++ community, GC is the MOST IMPORTANT ISSUE. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 6:30 AM
|
|
> I am sorry but any comment that starts with "none of the
> stuff I know off" can not be taken seriously. > > IMHO, for the C++ community, GC is the MOST IMPORTANT > ISSUE. IMHO, any comment that starts with IMHO cannot be taken seriously :) Joking aside, the fact is that a majority of developers don't want to use GC with C++. How many real life projects are there where C++ is used with GC? |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 23, 2006 1:37 AM
|
|
> Joking aside, the fact is that a majority of developers
> don't want to use GC with C++. How many real life projects > are there where C++ is used with GC? You are mistaking the effect for the cause. Real-life projects don't use GC with C++, because C++ does not have GC, libraries don't support GC, the STL does not support GC. I forgot to add to the reply to your previous statement that Eclipse, NetBeans etc are considerably slower than VS8, and VS8 is considerably slower than VS6...and this is because Java apps and VS8 are .NET applications, whereas VS6 is purely C++. |
|
Posts: 1 / Nickname: pkoch / Registered: June 5, 2006 11:01 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
November 15, 2006 8:20 AM
|
|
> > Joking aside, the fact is that a majority of developers
> > don't want to use GC with C++. Perhaps not. I guess it all depends on what you do. > > How many real life > projects > > are there where C++ is used with GC? There are quite a few, I believe. > > You are mistaking the effect for the cause. Real-life > projects don't use GC with C++, because C++ does not have > GC, libraries don't support GC, the STL does not support > GC. This is factually wrong. Nothing prevents you to rely on garbage-collection with C++. It requires that you observe a simple rule - namely to not "hide" any pointers (by e.g. writing them to disk). Although nothing in the C++ documentation prohibits this behaviour, I have not seen any standard library that performs such foul tricks so you can use that one with no problems at all. /Peter |
|
Posts: 5 / Nickname: david21001 / Registered: March 26, 2007 6:19 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
March 26, 2007 11:37 AM
|
|
leaks and crashes are from poor programming not the language itself...correct the programmer not the language
let's not dumb down C++ because some programmers don't know how to use pointers. that's what why there are languages like Java and C#, for those who can't use pointers ;) |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 19, 2006 4:48 AM
|
|
> no way to write programs like Firefox, Word, Powerpoint
> and Visio in languages other than C++, because those other > languages do not allow the performance of C++. None of those applications would be in my list as requiring C++ for performance reasons. Today, all could be implemented in a number of other languages without compromising the user experience. The choice at the time those projects were started probably was more restricted. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 4:03 AM
|
|
> > no way to write programs like Firefox, Word, Powerpoint
> > and Visio in languages other than C++, because those > other > > languages do not allow the performance of C++. > > None of those applications would be in my list as > requiring C++ for performance reasons. Today, all could be > implemented in a number of other languages without > compromising the user experience. The choice at the time > those projects were started probably was more restricted. No. With technical documents consisting of 100s of pages filled with text, images and diagrams, C++ is the only choice. Microsoft Office is written in C++. Sun started an office suite in Java, but they stopped it for being 'too slow'. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 5:21 AM
|
|
> Microsoft Office is written in C++.
Java did not exist at the time work on Office started. > Sun started an office suite in Java, but they stopped it > for being 'too slow'. A long time ago (in Java terms) this would have been true, but not in 2006. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 6:26 AM
|
|
> > Sun started an office suite in Java, but they stopped
> it > > for being 'too slow'. > A long time ago (in Java terms) this would have been true, > but not in 2006. It is true even today. Just look at Java IDE applications, like NetBeans, Eclipse, JEdit... Why do you think a new Java Office would be any different? The fundamental problem with Java is that it consumes "too much" memory, and that inevitably slows down the system. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 23, 2006 1:34 AM
|
|
> The fundamental problem with Java is that it consumes "too
> much" memory, and that inevitably slows down the system. Another problem is that C++ has a memory model which allows faster implementations; stack-based allocation can really speed up programs; and it is not the same as gc linear allocation, because the gc has to be locked for multiple thread access. The difference in performance grows exponentially with the size of the data set; handling a big Word document with Java would be quite slower than with C++. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 23, 2006 5:01 AM
|
|
> The difference in performance grows exponentially with the
> size of the data set; handling a big Word document with > Java would be quite slower than with C++. I can't imagine anyone using a garbage collector with cpu cost exponential in the size of the data. As for large documents, I wrote a little demonstration which was able to handle 100MB documents with ease. It is just a matter of using a suitable implementation for the Document. I routinely have applications with 300MB heaps. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 8:42 AM
|
|
> It is true even today. Just look at Java IDE applications,
> like NetBeans, Eclipse, JEdit... > > Why do you think a new Java Office would be any > different? > > The fundamental problem with Java is that it consumes "too > much" memory, and that inevitably slows down the system. Those applications use a lot of memory by choice of the developers, not as a result of the language used. Simply they are keeping a lot of data in memory. If you give them the amount of memory their developers expect you to use, they perform pretty well. Some of Microsoft's recent applications have exactly the same problem for exactly the same reason. This is not to say that Java and similar langauges don't tend to use a bit more memory, they do, but in most cases the language itself accounts for only a small portion of the memory used. For an app like NetBeans which gobbles > 100MB on even small projects, less than 20MB of this could be attributed to the use of Java, and this amount is essentially constant (doesn't grow with bigger projects). These days 20MB is of little consequence in a desktop environment. Over a decade ago, at an MS event, I heard one of their managers explain that you should target the amount of memory that will be typical on NEW machines at the time your product ships. Yes this means it might run like a dog on less well specified machines, BUT they weren't going to pay for your product any way. |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 20, 2006 9:31 AM
|
|
You claimed that Java is no longer slow and then you were provided with contemporary examples of slow Java applications which you then dismissed.
So give us some examples of contemporary java apps that perform as well or better than C++ apps. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 25, 2006 8:16 AM
|
|
> You claimed that Java is no longer slow and then you were
> provided with contemporary examples of slow Java > applications which you then dismissed. > > So give us some examples of contemporary java apps that > perform as well or better than C++ apps. Directly comparable applications written in two different languages are rather rare. For a fair comparison they also need to have been written at about the same time (otherwise the more recent app is likely to have been infected with the prevailing "memory is free" mentality). My own work is in vehicle routing --- optimising the routes and loading of vehicles. Computational performance is important here and yet I'm not bothered by doing it in Java. The previous major version of our system was written in C++ and we still have some C++ code in the current system (for historical not performance reasons). We are working to eliminate all of the remaining C++. At various stages during the development I have written benchmarks reflecting the type of computation we do and compare results in both Java and C++. Performance differences were in every case modest. I don't bother with testing against C++ anymore; I am confident I can achieve the required results and performance at least for the kind of work that I do. One part of the code is responsible for computing shortest paths between locations. On a network containing around 3 million arcs the Java version is around 10 times FASTER than the previous C++ code and is more flexible as well. Of course this difference is largely a result of an improved algorithm. The choice or development of algorithms are much more important than the choice of language. In this case the C++ code was a good implementation of an established algorithm, the Java code uses a completely new approach. |
|
Posts: 28 / Nickname: greggwon / Registered: April 6, 2003 1:36 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 21, 2006 8:26 PM
|
|
> You claimed that Java is no longer slow and then you were
> provided with contemporary examples of slow Java > applications which you then dismissed. I have no problems with any of these applications on my computer. What kind of computer with what kind of graphics card do you run your Java applications with? > So give us some examples of contemporary java apps that > perform as well or better than C++ apps. It's not just about performant apps. It's about programming productivity and application stability. I have very performant Java applications that bang away 24/7. The applications that were pointed out, all have something in common. They are desktop/GUI apps. The Swing implementation, currently, utilizes basic drawing primatives to render all components. This means that its rendering is more like a 2D/3D game's requirements than a "windows desktop app". So, it's no wonder that people without powerful graphics cards have poor results with Swing based applications. Eclipse/SWT can do better than Swing because it uses native drawing. But, in JDK-6, support for VISTA and Sun's realization that their rendering pipeline was not correct/optimal for windows, means that things are going to change, and I believe, for the better. Unfortunately, the masses are still all keyed in on CPU performance and don't understand the time they are wasting on writing complex code, debugging memory issues, and porting their software to a new OS/CPU combination. The design of Java is what enables it to be portable. The JDK1.5 memory model changes are what finally made it possible to write dependable multi-thread code. My largest applications which run with 100's of threads, will run equally well on Windows, Linux and MAC OS-X, without a single bit of porting work on the software base. The work on putting threads into C++ and the lack of GC are revealing the deficiencies it really has in its overall design. Applications with huge amounts of complex data structures are very difficult to get right. C++ makes it even harder, because you have to deal with memory management more explicitly either through finding the right library, or creating the memory model you need for yourself. C++ was never designed for a multi-threaded world, and it never will be able to really get there, with any dependable portability and operation, without a memory-model and then the standardized threading support that uses that memory-model. That's the effort that's underway now, and this report shows the issues that are going to have to be dealt with both technically, practically and religously. There are vendors today, providing OS based solutions, where they have control/advanced knowledge of the issues to deal with, including inparting a memory model in their compilers that makes it possible for them to support threading in some form. Thread designs that I saw in this report, based on library and templates, are very risky, because they utilize one of the more complex parts of the language specification. I'm anxious to see how things evolve toward a workable standard. But, in the end, I'm not at all sure it will happen without a "virtual machine" designed into the mix that provides the right level of abstraction that vendors can plug into. |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 22, 2006 9:49 AM
|
|
> It's not just about performant apps. It's about
> programming productivity and application stability. I > have very performant Java applications that bang away > 24/7. > I'm not sure why my post is quoted at the top of yours since what you said has little to do with what I said. |
|
Posts: 28 / Nickname: greggwon / Registered: April 6, 2003 1:36 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 24, 2006 9:00 PM
|
|
> > It's not just about performant apps. It's about
> > programming productivity and application stability. I > > have very performant Java applications that bang away > > 24/7. > > > > I'm not sure why my post is quoted at the top of yours > since what you said has little to do with what I said. You asked about performance and Mark's response to your questions. Without trying to answer for Mark, I was trying to find out more about your experience and perspective. I enumerated the issues and perspective that I'm familiar/experienced with. Java provides a platform that simplifies software development. In doing that, it generalizes certain things in that platform to make them more portable or more predictable. The result is that some things take more instructions to execute than if you coded them in assembly language. The difference is that you are trading some degree of performance for portability and speed of development. As James Gosling said, he enjoys write software in Java because it's possible to write correct software in Java, must faster and get better quality software, if you use the platform in the intended way. I'd still like to know what Java software you have practicle experience with in development and operations so that I can get a better understanding of your experiences and perspective. It's hard to really understand those things from your posts so far. I'd like to really discuss the issues and not throw around pointless arguments. |
|
Posts: 15 / Nickname: jr1 / Registered: February 12, 2006 6:32 PM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
October 25, 2006 5:17 PM
|
|
> You asked about performance and Mark's response to your
> questions. Actually, I never asked about Java performance, that was somebody else. I just observed that Mark's response when presented with examples of well-known contemporary Java applications that ran slower than comparable apps written in C/C++ seemed to me to be evasive. I don't deny that Java can sometimes allow faster development than C++, but that has nothing to do with run-time performance. Of course, we're all a bit-off topic anyway since the story was about standardizing threads in C++, not whether C++ is better than Java. |
|
Posts: 5 / Nickname: david21001 / Registered: March 26, 2007 6:19 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
March 26, 2007 11:48 AM
|
|
> > You claimed that Java is no longer slow and then you
> were > > provided with contemporary examples of slow Java > > applications which you then dismissed. > > I have no problems with any of these applications on my > computer. What kind of computer with what kind of > graphics card do you run your Java applications with? > > > So give us some examples of contemporary java apps that > > perform as well or better than C++ apps. > > It's not just about performant apps. It's about > programming productivity and application stability. I > have very performant Java applications that bang away > 24/7. > > The applications that were pointed out, all have something > in common. They are desktop/GUI apps. The Swing > implementation, currently, utilizes basic drawing > primatives to render all components. This means that its > rendering is more like a 2D/3D game's requirements than a > "windows desktop app". So, it's no wonder that people > without powerful graphics cards have poor results with > Swing based applications. Eclipse/SWT can do better than > Swing because it uses native drawing. But, in JDK-6, > support for VISTA and Sun's realization that their > rendering pipeline was not correct/optimal for windows, > means that things are going to change, and I believe, for > the better. > > Unfortunately, the masses are still all keyed in on CPU > performance and don't understand the time they are wasting > on writing complex code, debugging memory issues, and > porting their software to a new OS/CPU combination. > > The design of Java is what enables it to be portable. The > JDK1.5 memory model changes are what finally made it > possible to write dependable multi-thread code. My > largest applications which run with 100's of threads, will > run equally well on Windows, Linux and MAC OS-X, without a > single bit of porting work on the software base. > > The work on putting threads into C++ and the lack of GC > are revealing the deficiencies it really has in its > overall design. Applications with huge amounts of complex > data structures are very difficult to get right. C++ > makes it even harder, because you have to deal with memory > management more explicitly either through finding the > right library, or creating the memory model you need for > yourself. > > C++ was never designed for a multi-threaded world, and it > never will be able to really get there, with any > dependable portability and operation, without a > memory-model and then the standardized threading support > that uses that memory-model. That's the effort that's > underway now, and this report shows the issues that are > going to have to be dealt with both technically, > practically and religously. > > There are vendors today, providing OS based solutions, > where they have control/advanced knowledge of the issues > to deal with, including inparting a memory model in their > compilers that makes it possible for them to support > threading in some form. > > Thread designs that I saw in this report, based on library > and templates, are very risky, because they utilize one of > the more complex parts of the language specification. > > I'm anxious to see how things evolve toward a workable > standard. But, in the end, I'm not at all sure it will > happen without a "virtual machine" designed into the mix > that provides the right level of abstraction that vendors > can plug into. "C++ was never designed for a multi-threaded world, and it never will be able to really get there, with any dependable portability and operation, without a memory-model and then the standardized threading support that uses that memory-model. That's the effort that's underway now, and this report shows the issues that are going to have to be dealt with both technically, practically and religously." This is a false assumption -- C++ like C, was built to enable the maximum flexibility and keep it as light-weight as possible. I believe Dr. Stroustrup would tell you, go write your own threading library in C++. He even recommends the Boost library which has an implementation. C programs can be multi-threaded using the POSIX library -- the language has nothing to do with the subject. The question is whether the language should implement the behavior as part of it's standard library. Correct me if I am wrong here, but cross platform issues such as endian-ness are a function of the hardware. |
|
Posts: 5 / Nickname: david21001 / Registered: March 26, 2007 6:19 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
March 26, 2007 11:56 AM
|
|
Garbage Collection??? Are you out of your mind?
C++ is used in realtime applications, and embedded development. We don't want or need that concept. Again, competent C/C++ programmers don't have issues with dynamic memory allocation, pointer use, etc. And don't wish to have our language dumbed down. There is a reason why C has survived for so long. If memory wasn't so cheap, there would be greater emphasis on developing coding skill rather than trying to develop the language. There is a difference. |
|
Posts: 62 / Nickname: matt / Registered: February 6, 2002 7:27 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
March 29, 2007 9:07 AM
|
|
> Again, competent C/C++ programmers don't have issues with
> dynamic memory allocation, pointer use, etc. And don't > wish to have our language dumbed down. I think this part of your excursus is absolutely false. First of all, what do you mean by "competent C/C++" and in particular "C/C++"? To me, that often means C programmers who use a few C++ features -- and when I see code created by these people, I often see horrible code full of stuff like "goto ENDFUNC;" instead of doing things a competent C++ programmer would do, like using RAII. C and C++ are two different languages. There is also often a big difference between people who think they are competent and that very small minority who really are. I don't agree with the macho attitude (using better, more advanced development tools is not "dumbing down" -- by extension C programmers wusses, because they don't type in machine code directly!) that there are mythical "competent" C programmers who never make mistakes with pointers, buffers, arrays, resource leaks, etc. Very experienced and knowledgeable C programmers do and always will make such mistakes, because it is quite easy to do so and because they are all human. Even static analysis and annotations can't solve this problem, though they help a lot. If you want that statement to be true, then you need to say "... infallible C/C++ programmers don't have issues with dynamic memory allocation, pointer use, etc..." I do agree with you that C++ doesn't need garbage collection though and not just because of performance. There is definite value to deterministic destruction, for example. I think if you can use a garbage collected language, you should, otherwise you are just wasting development time. (I think people cling to C because they are affraid of losing their hard-earned status as a low-level guru.) If you are in some domain or platform that requires an unmanaged language, you should use C++, with good C++ idioms. If you must use C (I guess some embedded environments, driver code and low-level OS implementation still require it), use C. Is there ever any good reason to use "C/C++"? |
|
Posts: 1 / Nickname: happyjack2 / Registered: December 18, 2007 2:55 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
December 18, 2007 9:02 AM
|
|
A suggestion regarding C/C++ multi-threading standards:
Instead of having something like: mutex_lock (mutex); //do stuff mutex_release (mutex); I think it would be much clearer and easier on the programmer if they had a control-structure (since this IS flow-control, anyways) like so: sync (mutex) { //do stuff } more syntactically standard. easier to read. less typing. And for read/write, instead of upgradeable mutexes, one could have a "weaker" control structure: sync_read (mutex) { //do stuff } Which can run concurrently with other sync_reads for the same mutex, but has to wait on syncs. syncs, likewise, have to wait on sync_reads. Thus, all read and writes are sync. The concurrency restrictions (per mutex) would be: 1. all sync blocks must wait for any currently running sync block to complete, AND all currently running sync_read blocks to complete before executing. 2. all sync_reads blocks must wait for any currently running sync block to complete before executing. This guarantees that: 1. only one type of block (sync or sync_read) per mutex is running at a time 2. only one sync block (per mutex) is running at a time 3. any number of sync_read blocks (per mutex) may be running at a time 4. no write operations will be performed on the shared resource while any sync_read block is running Furthermore, for simplicity, one could have a global mutex per process, that is implied by omission: sync { //do stuff } Alternatively, these blocks could be called "atomic" because they guarantee atomic operations. Another suggestion I have for a multi-threading control structure would be a parallel loop block. Often times loops will be written where the operation of each iteration depends only on the iteration counter. in this case, iterations can be run in parallel by spawning multiple threads and joining them to the current one. parallel_for( init(i); condition; increment_op(i)) { //do stuff concurrently } the initialization instruction ("int i = 0") is not multi-threaded, of course. the increment operations are done in each thread, atomicly, at the beginning of each loop, and each iteration has its own local copy of i so as not to block other concurrent iterations. in cases where parts of the code inside the loop have concurrency issues, the above-mentioned sync/atomic blocks can be used to resolve them. |
|
Posts: 1 / Nickname: doubleshot / Registered: July 4, 2017 1:01 AM
Re: Trip Report: Ad-Hoc Meeting on Threads in C++
July 4, 2017 6:05 AM
|
|
I really can't understand why there are so many issues about C++ and threads. It just takes 200 lines of code to to write a C++ template class that allows easily the creation of threads of class methods.
|