While people as brilliant as Hans have already come up with the whole bunch of proposals and ideas which make me feel that threads in C++ will have a bright future, I did come across an article that seemingly said that there was something wrong with the way people did the whole thing. While I'm certainly not qualified to judge the thing, I'd like to put the post to the forefront, and let people who can to comment on this.
To quote a few lines(please redirect to the blog to see the details, coz I haven't asked the one if I could put the entire post(which is pretty long) here):
I'm reading this post on the C++ committee's dealings on threading, and, I am pleased to announce, there is absolutely no chance what so ever of anything sane, workable, or sensible accidentally arising from these precedings...
It appears the major gripe is the simplification to use fully synchronized atomic access and the effect on performance.
While for some code this may be a major factor, in most cases it is not.
Threading is a complex beast to most people, and so is C++. If the default model was to make things so complex that most people who are already familiar with threaded code become alienated by complexity, then we're not looking at a winning formula.
The few users with performance critical applications that need the control of load/store visibility can continue to experiment and there is nothing stopping them from using these "optimal" primitives in their applications - like they are today.
pon...@gmail.com wrote: > While people as brilliant as Hans have already come up with the whole > bunch of proposals and ideas which make me feel that threads in C++ > will have a bright future, I did come across an article that seemingly > said that there was something wrong with the way people did the whole > thing. > While I'm certainly not qualified to judge the thing, I'd like to put > the post to the forefront, and let people who can to comment on this.
He's basically only saying he doesn't like atomics because they disable optimizations. Given that it is simply their *goal*, this remark is just stupid.
He's also saying that a high-level language proposal was refused and the same proposal as a library was considered. It's simply because it was decided not to add needless elements to the language. Only low-level ones are added.
> I'm reading this post on the C++ committee's dealings on threading, > and, I am pleased to announce, there is absolutely no chance what so > ever of anything sane, workable, or sensible accidentally arising from > these precedings...
That guy clearly says he doesn't like C++. He probably doesn't even realize how C++ code should be. For example, he says he doesn't understand why so much attention was given to the design rather than the behaviour.
>While people as brilliant as Hans have already come up with the whole >bunch of proposals and ideas which make me feel that threads in C++ >will have a bright future, I did come across an article that seemingly >said that there was something wrong with the way people did the whole >thing. >While I'm certainly not qualified to judge the thing, I'd like to put >the post to the forefront, and let people who can to comment on this.
>To quote a few lines(please redirect to the blog to see the details, >coz I haven't asked the one if I could put the entire post(which is >pretty long) here):
>I'm reading this post on the C++ committee's dealings on threading, >and, I am pleased to announce, there is absolutely no chance what so >ever of anything sane, workable, or sensible accidentally arising from >these precedings...
I am greatly saddened by the tone of that article. He chooses to quote private discussions (and I am certain that he did so without the consent of the person quoted and without the context)
The comments are arrogant and if he was just an observer the blogger is unlikely to know as much as those who have been working on this solidly for over a year.
pon...@gmail.com wrote: > While people as brilliant as Hans have already come up with the whole > bunch of proposals and ideas which make me feel that threads in C++ > will have a bright future, I did come across an article that seemingly > said that there was something wrong with the way people did the whole > thing. > While I'm certainly not qualified to judge the thing, I'd like to put > the post to the forefront, and let people who can to comment on this.
> To quote a few lines(please redirect to the blog to see the details, > coz I haven't asked the one if I could put the entire post(which is > pretty long) here):
> I'm reading this post on the C++ committee's dealings on threading, > and, I am pleased to announce, there is absolutely no chance what so > ever of anything sane, workable, or sensible accidentally arising from > these precedings...
It is so much easier to stand up, shout, point and ridicule, than it is to actually help. People have been doing that since there were people.
Thank goodness there are some people who have the courage to put their hide on the line and make concrete proposals for a better standard. You can too. On the library side you can send proposals directly to me.
But check the attitude at the door. You may find out that you're not the only smart person working towards a better C++ standard.
Francis Glassborow wrote: > In article <1167139437.608835.58...@79g2000cws.googlegroups.com>, > pon...@gmail.com writes >> While people as brilliant as Hans have already come up with the whole >> bunch of proposals and ideas which make me feel that threads in C++ >> will have a bright future, I did come across an article that seemingly >> said that there was something wrong with the way people did the whole >> thing. >> While I'm certainly not qualified to judge the thing, I'd like to put >> the post to the forefront, and let people who can to comment on this.
>> To quote a few lines(please redirect to the blog to see the details, >> coz I haven't asked the one if I could put the entire post(which is >> pretty long) here):
>> I'm reading this post on the C++ committee's dealings on threading, >> and, I am pleased to announce, there is absolutely no chance what so >> ever of anything sane, workable, or sensible accidentally arising from >> these precedings...
> I am greatly saddened by the tone of that article. He chooses to quote > private discussions (and I am certain that he did so without the consent > of the person quoted and without the context)
Not to mention that it is almost certainly a mis-quote. I've said several times that the committee would be bad shape without Hans' encyclopedic knowledge of *garbage collection*. As for threading, the committee has a number of people with both broad and deep knowledge and experience.
Beman Dawes wrote: > Francis Glassborow wrote: > > I am greatly saddened by the tone of that article. He chooses to quote > > private discussions (and I am certain that he did so without the consent > > of the person quoted and without the context)
> Not to mention that it is almost certainly a mis-quote. I've said > several times that the committee would be bad shape without Hans' > encyclopedic knowledge of *garbage collection*. As for threading, the > committee has a number of people with both broad and deep knowledge and > experience.
> Beman Dawes wrote: > > Francis Glassborow wrote: > > > I am greatly saddened by the tone of that article. He chooses to quote > > > private discussions (and I am certain that he did so without the consent > > > of the person quoted and without the context)
> > Not to mention that it is almost certainly a mis-quote. I've said > > several times that the committee would be bad shape without Hans' > > encyclopedic knowledge of *garbage collection*. As for threading, the > > committee has a number of people with both broad and deep knowledge and > > experience.
Yes, it would have been most helpful if the blogger had referenced where he was getting his quotes from. I was familiar with the article and thus easily able to locate it as well. But others might not be, or might not go to the trouble to hunt the reference down.
They argue that multi threading is complicated and error prone, and that the alternative of using shared memory stores between native OS processes are to slow. But they say there is an alternative model. A mix between the two. You could have threads that dont share any data but only communicate thru messages. That kind of thread might sound alot like a regular native OS process but i guess the difference is that you have more control over them and they are more efficient because they are supported directly by the language instead of by the operating system.
Sounds simple and good to me. What do you guys think?
I guess the down side would be that to share any data you would be sending a copy of it. The cost of getting simple value semantics might just be worth it..
> They argue that multi threading is complicated and error prone, and > that the alternative of using shared memory stores between native OS > processes are to slow. But they say there is an alternative model. A > mix between the two. You could have threads that dont share any data > but only communicate thru messages. That kind of thread might sound > alot like a regular native OS process but i guess the difference is > that you have more control over them and they are more efficient > because they are supported directly by the language instead of by the > operating system.
> Sounds simple and good to me. What do you guys think?
This is already done informally in many multithreaded programs. The producer-consumer model, for example, is message-oriented in nature. But I do think it would be useful to formalize things further. Some projects have attempted this in modern adaptions of Hoare's CSP, but the designs I've seen aren't terrific from a semantic perspective. Also, I think CSP itself isn't sufficient, because it doesn't apply terribly well to distributed processing. And while the Pi calculus is useful here, it isn't that great for in-process concurrency. An ideal solution would adapt equally well to both low-latency and high-latency communication channels, but while I've seen some projects in this area (PEPA maybe? it's been a while since I looked), all were still in the design phase.
> I guess the down side would be that to share any data you would be > sending a copy of it. The cost of getting simple value semantics might > just be worth it..
For in-process concurrency, data doesn't necessarily have to be copied, it just can't be shared between threads. So I think the actual cost of messaging is generally quite acceptable.
> It is so much easier to stand up, shout, point and ridicule, than it > is to actually help. [...] Thank goodness there are some people who > have the courage to put their hide on the line and make concrete > proposals for a better standard. [...]
Threading is basically a solved problem and has been for a while. Someone mentioned Erlang. I'll mention Concurrent ML. I'll also mention first-class continuations which are supported by several languages and with which you can construct your own threading mechanism that looks like anything you want. Shoehorning threading into C++ just seems like a misallocation of talent and effort--counterproductive even. Is it "ridicule" to point this out?
In article <engf6f$c...@news.xmission.com>, Thant Tessman <a...@standarddeviance.com> writes
>Threading is basically a solved problem and has been for a while. >Someone mentioned Erlang. I'll mention Concurrent ML. I'll also mention >first-class continuations which are supported by several languages and >with which you can construct your own threading mechanism that looks >like anything you want. Shoehorning threading into C++ just seems like >a misallocation of talent and effort--counterproductive even. Is it >"ridicule" to point this out?
The only deduction I can make from this is that you believe C++ should be dead and buried. C++ without threading will be tantamount to useless by the end of this decade. Even mobile phones us multi-core processors these days. And my point is that multi-threading is in the process of becoming equivalent to concurrent programming and C++ needs to address that issue.
patrik.kah...@googlemail.com wrote: > You could have threads that dont share any data > but only communicate thru messages. > I guess the down side would be that to share any data you would be > sending a copy of it.
Unfortunetely, SMP architectures are more popular. So sharing is more efficient.
Francis Glassborow wrote: > The only deduction I can make from this is that you believe C++ should > be dead and buried. C++ without threading will be tantamount to useless > by the end of this decade. Even mobile phones us multi-core processors > these days. And my point is that multi-threading is in the process of > becoming equivalent to concurrent programming and C++ needs to address > that issue.
I have a threading library in C++ that is portable to Windows & Linux, and probably another other OS's where the kernel-mode people did their part and provided the minimum set of synchronization primitives. It is not a full-featured library. There are some questions that I did not try to answer. There are also some areas that could be cleaner. But the key point is that the interface is mostly clean, the interface is portable, the model does not leave you wrestling with your own brain as you use it, something I would imagine other people who have tried to make "thread objects" have discovered (I learned the hard way that it is not good to regard a thread as an object).
The point is that C++ and threading are alive and well. People use them together. Some people use the native API of their OS, which is not always pleasant to use. Some people wrap these API's.
But I do not think it is fair to say that we do not understand the importance of multi-threading programming by C++ programmers. We do. What we are saying is that the fundamentals of multi-threading, barring some massive break through in the state-of-the -art, are well-understood, and it is our opinion that those who think that the language itself is somehow deficient in this regard are mistaken.
Anything that the C++ community does with regard to "adding threading to the language" is going to eventually lead right to the primitives that actually implement synchronization, primitives that are 40 years old.
After all, when we talk about "threading", we are talking about synchronization.
Francis Glassborow wrote: I (Thant Tessman) wrote: >> [...] Shoehorning threading >> into C++ just seems like a misallocation of talent and >> effort--counterproductive even. [...]
Francis Glassborow replied:
> The only deduction I can make from this is that you believe C++ should > be dead and buried.
Yes. And I say this as someone who's made an admittedly comfortable living programming with C++ since cfront.
> C++ without threading will be tantamount to useless > by the end of this decade. Even mobile phones us multi-core processors > these days.
My first-hand experience is that mobile phones in practice are programmed usually with C, and/or a six, no, seven-year-out-of-date C++ compiler, and/or--just shoot me now--Java.
My guess is that future phones will be running either Linux, in which case one's options could go far beyond C++ for multi-threaded programming, or something from Microsoft, in which case they'll be pushing their CLR.
> And my point is that multi-threading is in the process of > becoming equivalent to concurrent programming and C++ needs to address > that issue.
Le Chaud Lapin wrote: > Francis Glassborow wrote: > > The only deduction I can make from this is that you believe C++ should > > be dead and buried. C++ without threading will be tantamount to useless > > by the end of this decade. Even mobile phones us multi-core processors > > these days. And my point is that multi-threading is in the process of > > becoming equivalent to concurrent programming and C++ needs to address > > that issue. > I have a threading library in C++ that is portable to Windows & Linux, > and probably another other OS's where the kernel-mode people did their > part and provided the minimum set of synchronization primitives. It is > not a full-featured library. There are some questions that I did not > try to answer. There are also some areas that could be cleaner. But > the key point is that the interface is mostly clean, the interface is > portable, the model does not leave you wrestling with your own brain as > you use it, something I would imagine other people who have tried to > make "thread objects" have discovered (I learned the hard way that it > is not good to regard a thread as an object). > The point is that C++ and threading are alive and well. People use > them together. Some people use the native API of their OS, which is > not always pleasant to use. Some people wrap these API's.
The point is that you don't know that it works, and that it works only by chance (and may actually fail once you start using a multi-core processor). The point is that you don't have any guarantees with regards to what the language or the compiler provides.
Maybe your happen with a definition of "working" as "it hasn't crashed yet", but my customers generally aren't.
> But I do not think it is fair to say that we do not understand the > importance of multi-threading programming by C++ programmers. We do. > What we are saying is that the fundamentals of multi-threading, barring > some massive break through in the state-of-the -art, are > well-understood,
Which explains why so many programmers get it wrong. (The people who implemented std::basic_string in g++ are not idiots; they're some of the more gifted programmers I know. Never the less, there is a threading error in the code.)
> and it is our opinion that those who think that the language > itself is somehow deficient in this regard are mistaken.
You can think what you like, but you can't argue with hard facts. It is impossible, today, to write a multi-threaded program with defined behavior.
> Anything that the C++ community does with regard to "adding threading > to the language" is going to eventually lead right to the primitives > that actually implement synchronization, primitives that are 40 years > old.
For the moment, I think the committee has only begun to scratch the surface with regards to primitives. Before defining the primitives, it is necessary to define a basic memory model; what it means to read or wite to memory.
> After all, when we talk about "threading", we are talking about > synchronization.
Hardly. There's a lot more to it than that.
-- James Kanze (Gabi Software) email: james.ka...@gmail.com Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze wrote: > Le Chaud Lapin wrote: > > The point is that C++ and threading are alive and well. People use > > them together. Some people use the native API of their OS, which is > > not always pleasant to use. Some people wrap these API's.
> The point is that you don't know that it works, and that it > works only by chance (and may actually fail once you start using > a multi-core processor). The point is that you don't have any > guarantees with regards to what the language or the compiler > provides.
I never asked the compiler for any guarantees. What did you study in university? I do not mean to attack you personally, but frankly, these concepts are as old as multi-threading itself. I am appalled that so many people seem not to understand multi-threading.
> Maybe your happen with a definition of "working" as "it hasn't > crashed yet", but my customers generally aren't.
One of my multi-threaded application has 11 threads in it at minimum, rising to 35 if necessary. This application will never crash "because of threading."
> > But I do not think it is fair to say that we do not understand the > > importance of multi-threading programming by C++ programmers. We do. > > What we are saying is that the fundamentals of multi-threading, barring > > some massive break through in the state-of-the -art, are > > well-understood,
> Which explains why so many programmers get it wrong. (The > people who implemented std::basic_string in g++ are not idiots; > they're some of the more gifted programmers I know. Never the > less, there is a threading error in the code.)
There is no "threading" error in the code. If I write
int x == 10;
int thread1 (); int thread2 ();
...and let those two threads fiddle with x without the protection of mutual-exclusion, there will be contention. Are you saying that the people who designed std:basic_string designed it expecting there would be no contention?
> > and it is our opinion that those who think that the language > > itself is somehow deficient in this regard are mistaken.
> You can think what you like, but you can't argue with hard > facts. It is impossible, today, to write a multi-threaded > program with defined behavior.
I do it every day. I know how to write multi-threaded applications. There are probably 10,000's of programmers who do. One should not assume that others are unable to do that which he cannot.
> For the moment, I think the committee has only begun to scratch > the surface with regards to primitives. Before defining the > primitives, it is necessary to define a basic memory model; what > it means to read or wite to memory.
I am going to give the committee the benefit of the doubt and assume that at least some of them understand the basics of synchronization and OS design. But the more I read this thread (no pun intended), the more I get the feeling is that real problem is simply that there C++-is-lacking-thread support crowd is primarily composed of people who have very little or no experience with multi-threading.
I wish someone who writes operating system books for a living were reading this. I cannot stop laughing as I am reading this post. The examples presented so far, two threads modifying a global variable....leaves me...speechless.
In all fairness, I know that there are probably a few lurking 16-year-olds who, though bright, having gotten around to mutual exclusion, and are so not sure who has more insight, so I offer this link to get you started so you can plainly see that this is a very old concept:
I did not study computer sciencel, but if you are reading this, and you studied computer science, and you do not understand the basics of mutual exclusion, or equivalently,
if you are in anyway, even _one iota_, surprised that a global static variable used by std::string cannot be accessed read/write by multiple threads without a mutex, I am sorry, there is simply no excuse - you should be ashamed of yourself! ?????? What do you expect??!!
> Shoehorning threading into C++ just seems like a > misallocation of talent and effort--counterproductive even.
Threading (concurrency + shared address space) is already in C++, and has been for years. The primary goal of the current standardization effort is to provide a formal specification backing that, to describe the behavior of the various library components under real-life MT conditions, and to provide a portable and standard way to get to the functionality that is already available, not to invent or to shoehorn.
Le Chaud Lapin wrote: > James Kanze wrote: > > You can think what you like, but you can't argue with hard > > facts. It is impossible, today, to write a multi-threaded > > program with defined behavior.
> I do it every day. I know how to write multi-threaded applications. > There are probably 10,000's of programmers who do. One should not > assume that others are unable to do that which he cannot.
Ooh! Bold assertion. Exactly the opposite of my experience. I am yet to meet a guy who knows a synchronization primitive from his backside and this is after he wrote an application that spawned 45 threads to do some activity.
> > For the moment, I think the committee has only begun to scratch > > the surface with regards to primitives. Before defining the > > primitives, it is necessary to define a basic memory model; what > > it means to read or wite to memory.
> I am going to give the committee the benefit of the doubt and assume > that at least some of them understand the basics of synchronization and > OS design. But the more I read this thread (no pun intended), the more > I get the feeling is that real problem is simply that there > C++-is-lacking-thread support crowd is primarily composed of people who > have very little or no experience with multi-threading.
Good heavens! How did a statement like that pass the moderators? This guy is giving the benefit of doubt to Hans Boehm? This kind of dual standards is very confusing. In another thread (subject: "Threads - When?") I tried to correct James Kanze's unfair (and uninformed) characterization of Jeffrey Richter as someone who has "no clue what multithreading is all about" and it never showed up even after 4 days and some thing like the above breezes right past in?
Le Chaud Lapin wrote: > James Kanze wrote: > > Le Chaud Lapin wrote: > > > The point is that C++ and threading are alive and well. People use > > > them together. Some people use the native API of their OS, which is > > > not always pleasant to use. Some people wrap these API's.
> > The point is that you don't know that it works, and that it > > works only by chance (and may actually fail once you start using > > a multi-core processor). The point is that you don't have any > > guarantees with regards to what the language or the compiler > > provides.
> I never asked the compiler for any guarantees. What did you study in > university? I do not mean to attack you personally, but frankly, these > concepts are as old as multi-threading itself. I am appalled that so > many people seem not to understand multi-threading.
Ahh... I guess you should seriously reconsider the issue.
Recommended reading is e.g. google: "why double checked guard does not work".
Just for starters, if you have
Shared y; Mutex y_lock;
void fn() { y_lock.Lock(); y = 10; y_lock.Unlock();
}
nothing in C++ standard prevents C++ compiler to generate machine code equivalent to
void fn() { y = 10; y_lock.Lock(); y_lock.Unlock();
}
(and now I recommend you to get some C++ reeducation before your threads start to fail with new compiler version ;)
Le Chaud Lapin wrote: > James Kanze wrote: >> Le Chaud Lapin wrote: >> > The point is that C++ and threading are alive and well. People use >> > them together. Some people use the native API of their OS, which is >> > not always pleasant to use. Some people wrap these API's.
>> The point is that you don't know that it works, and that it >> works only by chance (and may actually fail once you start using >> a multi-core processor). The point is that you don't have any >> guarantees with regards to what the language or the compiler >> provides.
> I never asked the compiler for any guarantees. What did you study in > university? I do not mean to attack you personally, but frankly, these > concepts are as old as multi-threading itself. I am appalled that so > many people seem not to understand multi-threading.
There are *important* threading related guarantees that the standard has nothing to say about. For example, there's no way to ensure that cached memory is consistent between two CPUs running two threads; you have no way to tell if a particular operation represents a synchronisation operation.
Further, the standard is silent on whether you can assume strict consistency, weak consistency, sequential consistency, causual consistency, or another consistency model.
These are both important if you want to guarantee that an operation between two threads working in parallel on the same block of memory does what you expect. In a weak consistency model, it's impossible to implement a working mutex without knowing which operations are synchronisation operations; your environment typically handles this by arbitrarily declaring that some library calls are synchronisation operations.
On top of this, in a weak consistency model, you need to know which operations are synchronisation operations to be certain that two processors have the same view of memory; without that knowledge, two different processors reading from the same bit of memory are entitled to return different values. -- Simon Farnsworth
> Le Chaud Lapin wrote: >> James Kanze wrote: [...] >> I never asked the compiler for any guarantees. What did you study in >> university? I do not mean to attack you personally, but frankly, these >> concepts are as old as multi-threading itself. I am appalled that so >> many people seem not to understand multi-threading.
> Ahh... I guess you should seriously reconsider the issue.
> Recommended reading is e.g. google: "why double checked guard does not > work".
Dilip wrote: > Le Chaud Lapin wrote: > > I do it every day. I know how to write multi-threaded applications. > > There are probably 10,000's of programmers who do. One should not > > assume that others are unable to do that which he cannot.
> Ooh! Bold assertion. Exactly the opposite of my experience. I am yet > to meet a guy who knows a synchronization primitive from his backside > and this is after he wrote an application that spawned 45 threads to do > some activity.
That's why I wrote ten's of thousands instead of millions. I could take the computer science students from the top computer science schools around the world. I think I would be able to find 10,000's of people in that group who understand the basics of synchronization.
> > I am going to give the committee the benefit of the doubt and assume > > that at least some of them understand the basics of synchronization and > > OS design. But the more I read this thread (no pun intended), the more > > I get the feeling is that real problem is simply that there > > C++-is-lacking-thread support crowd is primarily composed of people who > > have very little or no experience with multi-threading.
> Good heavens! How did a statement like that pass the moderators? This > guy is giving the benefit of doubt to Hans Boehm? This kind of dual > standards is very confusing. In another thread (subject: "Threads - > When?") I tried to correct James Kanze's unfair (and uninformed) > characterization of Jeffrey Richter as someone who has "no clue what > multithreading is all about" and it never showed up even after 4 days > and some thing like the above breezes right past in?
It is not a dual standard. The moderators let it pass probably because I was not the one who originally hinted that. And let's face it - there are lurkers in this group (trust me) reading this thread, and there is a strong polarization going on here. I can assure you that I am not the only one who feels that there is a disconnect regarding the difficulty to which multi-threading is done.
Hmm....reading this link gave me the same feeling I get when we were talking about whether C++ should be "migrated" to CLI, whether we should add GC to the language, whether the type system of C++ was fundamental or should be integrated with Microsoft's .NET CTS...
...basically, everything that involved changing C++ in such a way that it would be more like languages that are not like C++.
There is a pattern that seems to be going on. I will post more in a separate when I think I have figured out what that pattern is.
Are you saying that the C++ standard does not prescribe sequential execution of statements in a single-threaded program?
If that is the case, then I could write a single-threaded application that would not behave as a programmer would expect using an example very similar to the one you gave.
Also, do you have a link regarding the quote above for Google? I looked, and did not find what I think you were suggesting.
