C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Multithreaded programming: is the C++ standardization commit Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Andrei Alexandrescu (See Guest Posted: Wed Aug 18, 2004 12:05 pm    Post subject: Multithreaded programming: is the C++ standardization commit Years ago, Java decided to add support for multithreading to the core language. Many MT experts said that the support was not very good. Standard C++, as we all know, chose (and as far as I understand, is undecided as of the next standardization iteration) to stay away from MT altogether. Since then, a predictable sequence of events has happened. The Java community got better at what they were doing, and the C++ community continued to segregate deeper and deeper among standard-conforming programmers who don't use MT, multi-standard programmers who use, say, pthreads and its C binding (and tread carefully as far as mixing C++ with pthreads go), and hard-core MT programmers who use nonportable documentation provided by their own platform and compiler. Once it became evident that threads must be part of the language, the pursuit of better language-level abstractions for multithreading naturally continued within the Java research and industrial communities. Also, hard-core C and C++ MT programmers became a more and more isolated clique (occasionally perceived at snooty by the standard-compliant programmers who don't understand the complexities that are at stake). As a result, much of the research on the recent lock-free data structures (which surpass the now-familiar lock-based structures in performance) has been done in Java or uses C/C++ only as "pseudocode", the real C/C++ code being not portable. Java even has lock-free structures in their current distribution ([url]http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html)[/url]. If this trend will continue, soon Java will be the language of choice for portable multithreaded programming, and standard C++ will be out in the cold clenching its teeth. Does the C++ standardization committee plan to address threads at all, or continue to ignore them? Andrei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Wed Aug 18, 2004 6:34 pm    Post subject: Re: Multithreaded programming: is the C++ standardization co In article <2ofbi8F9v4qkU1 (AT) uni-berlin (DOT) de>, "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes Quote: Does the C++ standardization committee plan to address threads at all, or continue to ignore them? I would have thought that someone with your level of expertise would be exactly the kind of person WG21 could expect to propose such a feature, and then pursue the issue to its completion. What about a preliminary paper from you (which should include consideration of current library based proposals) for the next meeting. That meeting is just down the road for you and so it should not be too difficult for you to attend and present the paper. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Guest Posted: Wed Aug 18, 2004 6:46 pm    Post subject: Re: Multithreaded programming: is the C++ standardization co On Wed, 18 Aug 2004 12:05:56 UTC, "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote: Quote: Years ago, Java decided to add support for multithreading to the core language. Many MT experts said that the support was not very good. Standard C++, as we all know, chose (and as far as I understand, is undecided as of the next standardization iteration) to stay away from MT altogether. Since then, a predictable sequence of events has happened. The Java community got better at what they were doing, and the C++ community continued to segregate deeper and deeper among standard-conforming programmers who don't use MT, multi-standard programmers who use, say, pthreads and its C binding (and tread carefully as far as mixing C++ with pthreads go), and hard-core MT programmers who use nonportable documentation provided by their own platform and compiler. Once it became evident that threads must be part of the language, the pursuit of better language-level abstractions for multithreading naturally continued within the Java research and industrial communities. Also, hard-core C and C++ MT programmers became a more and more isolated clique (occasionally perceived at snooty by the standard-compliant programmers who don't understand the complexities that are at stake). As a result, much of the research on the recent lock-free data structures (which surpass the now-familiar lock-based structures in performance) has been done in Java or uses C/C++ only as "pseudocode", the real C/C++ code being not portable. Java even has lock-free structures in their current distribution ([url]http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html)[/url]. If this trend will continue, soon Java will be the language of choice for portable multithreaded programming, and standard C++ will be out in the cold clenching its teeth. Does the C++ standardization committee plan to address threads at all, or continue to ignore them? Andrei Andrei, While I understand your position, it would be unreasonable to add a thread concept to either the C or C++ standards. The primary reason for this would be that the compiler would need to know how the target computer implements threads and if it did not, for it to provide some underlying code to pretend that threading did exist. While we can compare C/C++ vs. Java as languages, Java also has certain other concepts that C/C++ does not. Java has the sandbox, files, threads/processes, and other concepts more associated with a definition of an operating system. While it may be useful to have C/C++ provide these extensions, their use/capability/reliability might be unpredictable on certain systems. C/C++ was not intended to provide the notion of even a single thread -- it defines a sequence of operations. Much of my work is on systems that are at the embedded or kernel level. Perhaps 40% of my time is spent in the apllication world. Yet most of my code is C/C++. Assembler, Forth, Java, Ada, and a few others are used perhaps once a year. Adding a thread concept to C/C++ would not be beneficial at my level of coding since it would require knowledge of the system. David [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Andrei Alexandrescu (See Guest Posted: Thu Aug 19, 2004 12:01 pm    Post subject: Re: Multithreaded programming: is the C++ standardization co "David" <FlyLikeAnEagle (AT) United (DOT) Com> wrote Quote: While I understand your position, it would be unreasonable to add a thread concept to either the C or C++ standards. The primary reason for this would be that the compiler would need to know how the target computer implements threads and if it did not, for it to provide some underlying code to pretend that threading did exist. Not necessarily. That's actually a fallacy that I'd like to dispel right here and now. When writing std::cout << "Hello, world! World? World? Where are you?n"; a program might not display anything anywhere. There are systems without a console, and there are systems (such as Windows) in which you could display a console if you wanted, but only by using nonstandard calls. On those systems, the code above compiles and links but doesn't do zilch. And nobody blinks an eye. Do systems lacking a console simulate it? No. Why, then, saying that no thread support means that the language would need to simulate it on machines that don't have it? On those machines, calls to thread creation functions would fail, and the synchronization-related keywords and classes will do nothing. And nobody will blink an eye. Quote: While we can compare C/C++ vs. Java as languages, Java also has certain other concepts that C/C++ does not. Java has the sandbox, files, threads/processes, and other concepts more associated with a definition of an operating system. C++ does have files, doesn't it. "Java already has things C++ doesn't" is not a serious argument anyway. If Java has good things, then why not looking into doing those good things, and preferably better. Quote: While it may be useful to have C/C++ provide these extensions, their use/capability/reliability might be unpredictable on certain systems. C/C++ was not intended to provide the notion of even a single thread -- it defines a sequence of operations. I know that. I am talking about the upcoming standardization step. Quote: Much of my work is on systems that are at the embedded or kernel level. Perhaps 40% of my time is spent in the apllication world. Programmer time or application time? ) Quote: Yet most of my code is C/C++. Assembler, Forth, Java, Ada, and a few others are used perhaps once a year. Adding a thread concept to C/C++ would not be beneficial at my level of coding since it would require knowledge of the system. I understand that. But providing performant portable threading would empower a lot of programmers who spend 90% of their programming time writing portable applications. Andrei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Hyman Rosen Guest Posted: Thu Aug 19, 2004 12:08 pm    Post subject: Re: Multithreaded programming: is the C++ standardization co David wrote: Quote: The primary reason for this would be that the compiler would need to know how the target computer implements threads and if it did not, for it to provide some underlying code to pretend that threading did exist. First of all, how is "pretend threading" different from "real threading"? Second, Ada provides support for concurrency defined portably within the language without any trouble at all. So does Java, for that matter, albeit less well. Quote: Much of my work is on systems that are at the embedded or kernel level. Then you should certainly be aware of Ada and its tasking mechanisms. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Adam Zell Guest Posted: Thu Aug 19, 2004 12:12 pm    Post subject: Re: Multithreaded programming: is the C++ standardization co "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote: : Java even has lock-free structures in their current distribution : ([url]http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html)[/url]. : If this trend will continue, soon Java will be the language of choice for : portable multithreaded programming, and standard C++ will be out in the cold : clenching its teeth. : Many lock-free algorithms depend on garbage collection, which puts the discussion back into the great GC debate. Other methods for GC-like management (such as Michael's SMR) are complex, or untested in production. http://www.research.ibm.com/people/m/michael/podc-2002.pdf http://www.cs.tau.ac.il/~shanir/reading%20group/p73-michael.pdf [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Antonio Maiorano Guest Posted: Fri Aug 20, 2004 12:28 am    Post subject: Re: Multithreaded programming: is the C++ standardization co "David" <FlyLikeAnEagle (AT) United (DOT) Com> wrote <snip> Quote: Much of my work is on systems that are at the embedded or kernel level. Perhaps 40% of my time is spent in the apllication world. Yet most of my code is C/C++. Assembler, Forth, Java, Ada, and a few others are used perhaps once a year. Adding a thread concept to C/C++ would not be beneficial at my level of coding since it would require knowledge of the system. David Hi David, I'm not sure I understand your reasoning. You say that it would not be beneficial to have threading concepts in C++ because it would require for you to have knowledge of the system, but that is exactly the problem we have now because there is NO threading concept in C++. Now to code a multithreaded program in C/C++, you must read and understand the platform-specific APIs. Not only is this time-consuming, but the subtle differences between platforms are usually learned the hard way. Perhaps you meant to say that programming multithreaded code is different on all systems, and should not be part of the language. This has often been the argument against it, but I must disagree with this wholeheartedly. Wherever I've worked, we've always had some abstraction of threads and thread locking constructs in some library that is cross-platform. Indeed, Boost.Thread exists for this reason. Fact is, if C++ finally included some multithreaded constructs as part of the standard, then vendors would finally be forced to implement them on the different platforms. If the lowest common denomintator provided by the language would not give you enough control, then you could always turn to the platform-specific library, but that would be up to the programmer. -- Antonio Maiorano Software Engineer, Electronic Arts E-Mail: m a i o r a n o AT v i d e o t r o n DOT c a [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Joe Seigh Guest Posted: Fri Aug 20, 2004 12:30 am    Post subject: Re: Multithreaded programming: is the C++ standardization co David wrote: Quote: While I understand your position, it would be unreasonable to add a thread concept to either the C or C++ standards. The primary reason for this would be that the compiler would need to know how the target computer implements threads and if it did not, for it to provide some underlying code to pretend that threading did exist. It's not necessary for the compiler to implement threading. That can be done in a library. It would be nice for the compiler to supply the primitives necessary to implement threading correctly, things like optimization directives, memory alignment, how to avoid word tearing, etc... The abstract concept of threading is well understood, you don't really need to define that. You also don't need to define a memory model, just assume totally ordered memory and let the thread api implementors use the optimization directives and platform dependent memory barriers to deal with that. Joe Seigh [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nicola Musatti Guest Posted: Fri Aug 20, 2004 12:50 am    Post subject: Re: Multithreaded programming: is the C++ standardization co "David" <FlyLikeAnEagle (AT) United (DOT) Com> wrote [...] Quote: While I understand your position, it would be unreasonable to add a thread concept to either the C or C++ standards. The primary reason for this would be that the compiler would need to know how the target computer implements threads and if it did not, for it to provide some underlying code to pretend that threading did exist. While we can compare C/C++ vs. Java as languages, Java also has certain other concepts that C/C++ does not. Java has the sandbox, files, threads/processes, and other concepts more associated with a definition of an operating system. I agree with you. In a way Andrei is addressing the wrong body, when probably he should lobby Microsoft and the Open Group (and possibly others for less common platforms) to get together and develop a portable, modern C++ API to the underlying OS services. Even if the two were to develop independent, incompatible API's it would be an improvement over the current situation. Cheers, Nicola Musatti [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Tokyo Tomy Guest Posted: Fri Aug 20, 2004 12:59 am    Post subject: Re: Multithreaded programming: is the C++ standardization co "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote Quote: Years ago, Java decided to add support for multithreading to the core language. Many MT experts said that the support was not very good. Standard C++, as we all know, chose (and as far as I understand, is undecided as of the next standardization iteration) to stay away from MT altogether. Since then, a predictable sequence of events has happened. ... I expect thread in the C++ standard. We need a common base line of MT programming, which is useful in many MT applications, but not in all MT applications. I like boost:thread, because it is simple for beginners like me, but apparently not so versatile for MT experts. For example, boost:thread cannot control the thread priority. Many portable thread libraries available today show limitations which come from the portability. Portable thread libraries must lower the level of functions within the GCM (Greatest Common Measure) among functions provided by platforms. Windows provides named mutex which can give a lock beyond process boundary, but other platforms do not provide such a mutex or give other mechanisms to do so. Therefore, it is impossible to make up a portable versatile MT library which satisfies MT experts. But please give us a base line for MT programming. Look at File system: We have at least four methods to handle files on Windows. 1. C style 2. C++ style 3. Win32 style 4. MFC style I usually use C++ style, but I have a freedom to use Win32 style for more file security. I usually use std::string, but sometime I use CString for windows programming. C++ programmers have this kind of freedom, but I don't think Java programmers do have, because their programs must work on the JVM, which gives portability. It may be true: Quote: Years ago, Java decided to add support for multithreading to the core language. Many MT experts said that the support was not very good. But, will not be true for C++, I think. Maybe, C++ can do without change of core language. Quote: As a result, much of the research on the recent lock-free data structures (which surpass the now-familiar lock-based structures in performance) has been done in Java or uses C/C++ only as "pseudocode", the real C/C++ code being not portable. Lock-free data structures are charming. I hope the idea has nothing to do with GC. If so, C++ must provide a conventional locking mechanism at least. Anyway, C++ needs a base line for MT programming. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Craig Guest Posted: Fri Aug 20, 2004 1:03 am    Post subject: Re: Multithreaded programming: is the C++ standardization co David wrote: <snip> Quote: Andrei, While I understand your position, it would be unreasonable to add a thread concept to either the C or C++ standards. The primary reason for this would be that the compiler would need to know how the target computer implements threads and if it did not, for it to provide some underlying code to pretend that threading did exist. While we can compare C/C++ vs. Java as languages, Java also has certain other concepts that C/C++ does not. Java has the sandbox, files, threads/processes, and other concepts more associated with a definition of an operating system. While it may be useful to have C/C++ provide these extensions, their use/capability/reliability might be unpredictable on certain systems. C/C++ was not intended to provide the notion of even a single thread -- it defines a sequence of operations. Much of my work is on systems that are at the embedded or kernel level. Perhaps 40% of my time is spent in the apllication world. Yet most of my code is C/C++. Assembler, Forth, Java, Ada, and a few others are used perhaps once a year. Adding a thread concept to C/C++ would not be beneficial at my level of coding since it would require knowledge of the system. David Perhaps what Andrei should be proposing is a threading standard library. We have the STL which is present on most platforms and gives us very useful standard containers that behave identically on each platform. I see a standard threading model as being the best way forward. If an existing threading model was adopted it could be used exactly like the STL is and to the same effect. I do hope the docs are better though!<grin> Which thread model though? Posix? Daves comments are very important and a Standard Thread model is the only way I see for it to be integrated into the C++ language. BTW comparing Java which runs in a virtual machine to C++ with regard to threads etc. is a little unfair. I find C++ increasingly frustrating to use when Java is so much more productive in some types of programming. Craig [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Robert Kindred Guest Posted: Fri Aug 20, 2004 1:19 am    Post subject: Re: Multithreaded programming: is the C++ standardization co "David" <FlyLikeAnEagle (AT) United (DOT) Com> wrote Quote: On Wed, 18 Aug 2004 12:05:56 UTC, "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote: [] Quote: Does the C++ standardization committee plan to address threads at all, or continue to ignore them? Andrei Andrei, While I understand your position, it would be unreasonable to add a thread concept to either the C or C++ standards. The primary reason for this would be that the compiler would need to know how the target computer implements threads and if it did not, for it to provide some underlying code to pretend that threading did exist. Actually, compilers don't know many other things, such as how to open a file. This is left to the run-time library. Also, the original threads library did not use the operating system. I don't know of an official name for fork/join/quit, but it was a convenient way for the programmer to express parallelism, though there was no support from the os. I have seen this used in DOS. Since each pseudo-thread implemented run-to-completion, it was also more efficient than "real" threading. If I wrote a C++ program that used a standardized threading system, I would be satisfied that it ran unchanged in DOS. It is not possible to over-emphasize the importance of standards. [] of coding since it would require knowledge of the system. Quote: David [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Craig Henderson Guest Posted: Fri Aug 20, 2004 1:20 am    Post subject: Re: Multithreaded programming: is the C++ standardization co "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote Quote: When writing std::cout << "Hello, world! World? World? Where are you?n"; a program might not display anything anywhere. There are systems without a console, and there are systems (such as Windows) in which you could display a console if you wanted, but only by using nonstandard calls. On those systems, the code above compiles and links but doesn't do zilch. And nobody blinks an eye. Do systems lacking a console simulate it? No. Why, then, saying that no thread support means that the language would need to simulate it on machines that don't have it? On those machines, calls to thread creation functions would fail, and the synchronization-related keywords and classes will do nothing. And nobody will blink an eye. Fail? Isn't that inconsistent? In a Windows environment, for example, does this throw an exception? std::cout << "Hello, world! World? World? Where are you?n"; if (std::cout.fail()) throw runtime_error("No console"); No, it fails silently. Craig [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Balog Pal Guest Posted: Fri Aug 20, 2004 1:21 am    Post subject: Re: Multithreaded programming: is the C++ standardization co "Francis Glassborow" <francis (AT) robinton (DOT) demon.co.uk> wrote Quote: In article <2ofbi8F9v4qkU1 (AT) uni-berlin (DOT) de>, "Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes Does the C++ standardization committee plan to address threads at all, or continue to ignore them? I would have thought that someone with your level of expertise would be exactly the kind of person WG21 could expect to propose such a feature, and then pursue the issue to its completion. What about a preliminary paper from you (which should include consideration of current library based proposals) for the next meeting. That meeting is just down the road for you and so it should not be too difficult for you to attend and present the paper. Yess. YESS! :) Even if a mere outline or summary of what we see now it could be a start. And a magnet for contributions. Paul [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Balog Pal Guest Posted: Fri Aug 20, 2004 1:22 am    Post subject: Re: Multithreaded programming: is the C++ standardization co "David" <FlyLikeAnEagle (AT) United (DOT) Com> wrote Quote: While I understand your position, it would be unreasonable to add a thread concept to either the C or C++ standards. The primary reason for this would be that the compiler would need to know how the target computer implements threads and if it did not, for it to provide some underlying code to pretend that threading did exist. Would you explain that in detail? Suppose C++ formally defined threads, memory model, rules of interthread communications. And put in some essential primitives like mutex and thread_start. Now how that applies to a compiler already having thread support: it just have to map the few primitives to OS calls (like it implements the C library or anything). [and certainly revise the library for std-mandated thread-safety where necessary.] Where no thread support exist all the primitives do nothing and the call to thread_start always fails with 'no resources to start yet another thread'. Just like it could fail with thread support on asking too much. Having threads standardized would relieve uys from poking tons of other documents or rely on heuristics. As we can an do use threads even now with C++ on many platforms, just it is cumbersome and puts us in a fragile situation. Quote: While it may be useful to have C/C++ provide these extensions, their use/capability/reliability might be unpredictable on certain systems. You mean systems already with or without OS threading support? Quote: C/C++ was not intended to provide the notion of even a single thread -- it defines a sequence of operations. That's how generally a thread is defined IMHO. So we already have defined behavior of a single thread. TODO is definig interaction with another. Paul [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next Page 1 of 9   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  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 Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.