Re: [boost] Boost.Threads, N2178, N2184, et al
RAII? If the response is "API on top of pthreads" then why discuss pthreads at all? -----Original Message----- From: boost-bounces@lists.boost.org on behalf of Emil Dotchevski Sent: Sat 3/24/2007 12:07 PM To: boost@lists.boost.org Subject: Re: [boost] Boost.Threads, N2178, N2184, et al But let's turn things over: why not use pthread instead of creating another API? I think it is clear that using pthreads has a few advantages. What is the drawback?
But let's turn things over: why not use pthread instead of creating another API? I think it is clear that using pthreads has a few advantages. What is the drawback?
RAII?
If the response is "API on top of pthreads" then why discuss pthreads at all?
Here is how I understand your question: does it make sense to formalize a lower level API behind <thread>. If we lived in a world where pthreads did not exist, I wouldn't care much one way or another; but we don't. So I think you're asking the wrong question. I think it's more appropriate to ask ourselves: 1) Given that pthreads is already a very solid formal standard, and given that there is a lot of legacy code already written for it, does it make sense to also formally standardize it as the abstraction layer of the C++ <thread> support? 2) Does adopting pthreads as the standard lower level abstraction of the C++ <thread> layer make it in any way harder to implement the C++ <thread> layer, compared to an implementation that does not formalize a lower level interface? 3) Does a formal pthread layer introduce any overhead in the higher level C++ <thread> layer? In particular we need to examine the answer to 2) and 3) wrt the Windows <thread> implementation, since on Posix the answer is clear. Emil Dotchevski
Emil Dotchevski wrote:
Here is how I understand your question: does it make sense to formalize a lower level API behind <thread>.
You understand correctly. This is the question I ask, and the answer I give is "no".
If we lived in a world where pthreads did not exist, I wouldn't care much one way or another; but we don't.
The fact that pthreads exist is completely irrelevant. We setup a C++ standard, and it should be as good as it gets. The POSIX model is good, so we take it. The POSIX syntax is not so good (for C++, obviously) so we don't take it.
So I think you're asking the wrong question.
I disagree. I think the question I'm asking is spot on, really. ;-)
I think it's more appropriate to ask ourselves:
1) Given that pthreads is already a very solid formal standard, and given that there is a lot of legacy code already written for it, does it make sense to also formally standardize it as the abstraction layer of the C++ <thread> support?
Sorry, but I think not.
2) Does adopting pthreads as the standard lower level abstraction of the C++ <thread> layer make it in any way harder to implement the C++ <thread> layer, compared to an implementation that does not formalize a lower level interface?
3) Does a formal pthread layer introduce any overhead in the higher level C++ <thread> layer?
I haven't checked it in depth, but if you say no, then I'll take your word for it.
In particular we need to examine the answer to 2) and 3) wrt the Windows <thread> implementation, since on Posix the answer is clear.
Disagreement again. Question 1 is not to be overlooked at all. The C++ moto is "don't pay for what you don't need". I'll add to that "don't standardize what you don't need". Less is more, and stuff like that.
Emil Dotchevski wrote:
Here is how I understand your question: does it make sense to formalize a lower level API behind <thread>.
You understand correctly. This is the question I ask, and the answer I give is "no".
If we lived in a world where pthreads did not exist, I wouldn't care much one way or another; but we don't.
The fact that pthreads exist is completely irrelevant. We setup a C++ standard, and it should be as good as it gets. The POSIX model is good, so we take it. The POSIX syntax is not so good (for C++, obviously) so we don't take it.
What follows then, is that you would like existing pthread C libraries to continue to be non-portable. I don't see why. I might be blind, but I don't see why would that be desirable.
<snip>
2) Does adopting pthreads as the standard lower level abstraction of the C++ <thread> layer make it in any way harder to implement the C++ <thread> layer, compared to an implementation that does not formalize a lower level interface?
3) Does a formal pthread layer introduce any overhead in the higher level C++ <thread> layer?
I haven't checked it in depth, but if you say no, then I'll take your word for it.
I haven't checked in depth either. But I'm very interested to know the answer.
In particular we need to examine the answer to 2) and 3) wrt the Windows <thread> implementation, since on Posix the answer is clear.
Disagreement again. Question 1 is not to be overlooked at all. The C++ moto is "don't pay for what you don't need". I'll add to that "don't standardize what you don't need". Less is more, and stuff like that.
While strictly speaking I do not *need* to use existing C libraries in my C++ code, I *want* to be able to. And I mean this in general, not just for threading libraries. Emil Dotchevski
Emil Dotchevski wrote: <Snip>
While strictly speaking I do not *need* to use existing C libraries in my C++ code, I *want* to be able to. And I mean this in general, not just for threading libraries.
Emil Dotchevski
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think what is needed for pthreads to be standardized would be for the C programming language group to standardize it not the C++. I seriously doubt they would standardize something which belongs in the purview of the C group which pthreads does IMO.
Emil Dotchevski wrote:
Emil Dotchevski wrote:
Here is how I understand your question: does it make sense to formalize a lower level API behind <thread>. You understand correctly. This is the question I ask, and the answer I give is "no".
If we lived in a world where pthreads did not exist, I wouldn't care much one way or another; but we don't. The fact that pthreads exist is completely irrelevant. We setup a C++ standard, and it should be as good as it gets. The POSIX model is good, so we take it. The POSIX syntax is not so good (for C++, obviously) so we don't take it.
What follows then, is that you would like existing pthread C libraries to continue to be non-portable. I don't see why. I might be blind, but I don't see why would that be desirable.
I never said that. If the C standard committee decides to fully adopt pthreads, I'd be fine with it. And if the C++ standard committee decides to be backwards compatible with C, and also adopt pthreads, I'd be fine with that too. I just don't think it should come instead of "the best" C++ interface, which is what I care about most.
I haven't checked in depth either. But I'm very interested to know the answer.
In particular we need to examine the answer to 2) and 3) wrt the Windows <thread> implementation, since on Posix the answer is clear. Disagreement again. Question 1 is not to be overlooked at all. The C++ moto is "don't pay for what you don't need". I'll add to that "don't standardize what you don't need". Less is more, and stuff like that.
While strictly speaking I do not *need* to use existing C libraries in my C++ code, I *want* to be able to. And I mean this in general, not just for threading libraries.
Ok, so we come again to what seems to be the true heart of the debate. Do we want interoperability between the C library and the C++ library, and how much are we willing to pay for it. And it seems we give different answers to this question.
Yuval Ronen wrote:
Ok, so we come again to what seems to be the true heart of the debate. Do we want interoperability between the C library and the C++ library, and how much are we willing to pay for it. And it seems we give different answers to this question.
One reason for the different answers to this question is that you seem to be attributing costs where there may be none, without bothering to go into specifics so that your claims can be either challenged or acknowledged and justified. If you list specific concerns with the idea of basing <thread> on <pthread.h>, we'll be able to stick to technicalities and move away from what seems to have become a flame war - and maybe even produce something useful as a result of the discussion.
Peter Dimov wrote:
Yuval Ronen wrote:
Ok, so we come again to what seems to be the true heart of the debate. Do we want interoperability between the C library and the C++ library, and how much are we willing to pay for it. And it seems we give different answers to this question.
One reason for the different answers to this question is that you seem to be attributing costs where there may be none, without bothering to go into specifics so that your claims can be either challenged or acknowledged and justified.
Ok, here's an example. It's about mutexes. Bear in mind that I'm talking about interface design costs, not performance costs. If I want my C code to access C++ mutexes I have to expose the pthread_mutex_t member from the std::mutex class. That's a cost (albeit a minor one). If I want my C++ code to access C mutexes I have to make a std::mutex refer to some pthread_mutex_t that is not a member of it. That's a more major cost.
If you list specific concerns with the idea of basing <thread> on <pthread.h>, we'll be able to stick to technicalities and move away from what seems to have become a flame war - and maybe even produce something useful as a result of the discussion.
Flame war? God forbid, no. I have the utmost respect for everybody involved (including myself ;-)). Was I getting personal at any stage? If so, my deep apologies. In general I can say that there's nothing wrong with accepting <pthread.h>, but basing <thread> on it is simply not necessary. Being the minimalist I am, I think that if it doesn't need to be, it needs to be not. Do what you have to, nothing more, nothing less.
Yuval Ronen wrote:
Peter Dimov wrote:
Yuval Ronen wrote:
Ok, so we come again to what seems to be the true heart of the debate. Do we want interoperability between the C library and the C++ library, and how much are we willing to pay for it. And it seems we give different answers to this question. One reason for the different answers to this question is that you seem to be attributing costs where there may be none, without bothering to go into specifics so that your claims can be either challenged or acknowledged and justified.
Ok, here's an example. It's about mutexes. Bear in mind that I'm talking about interface design costs, not performance costs.
If I want my C code to access C++ mutexes I have to expose the pthread_mutex_t member from the std::mutex class. That's a cost (albeit a minor one). If I want my C++ code to access C mutexes I have to make a std::mutex refer to some pthread_mutex_t that is not a member of it. That's a more major cost.
Rereading this example makes me think it confuses more than explains... So to rephrase what I wanted to say in the most concise manner - the cost I was talking about is that the interoperability requirement makes N2184 impossible. As simple as that. And if I consider N2184 desirable, it's a quite a cost.
Yuval Ronen wrote:
So to rephrase what I wanted to say in the most concise manner - the cost I was talking about is that the interoperability requirement makes N2184 impossible. As simple as that.
I've no idea what you mean, sorry. What part of N2184 is impossible and why?
Peter Dimov wrote:
Yuval Ronen wrote:
So to rephrase what I wanted to say in the most concise manner - the cost I was talking about is that the interoperability requirement makes N2184 impossible. As simple as that.
I've no idea what you mean, sorry. What part of N2184 is impossible and why?
It depends on what kind of interoperability we're talking about. If we want to manipulate in C++ mutexes created in C or vice versa, then the example from the previous post explains it. If we want to manipulate in C++ threads created in C or vice versa, then we have pthread_t exposition problems which are the basically same problems as described for mutexes, and in addition, we also have the join/cancel problems which were described elaborately by Howard.
Yuval Ronen wrote:
Peter Dimov wrote:
Yuval Ronen wrote:
So to rephrase what I wanted to say in the most concise manner - the cost I was talking about is that the interoperability requirement makes N2184 impossible. As simple as that.
I've no idea what you mean, sorry. What part of N2184 is impossible and why?
It depends on what kind of interoperability we're talking about. If we want to manipulate in C++ mutexes created in C or vice versa, then the example from the previous post explains it.
There are no mutexes in N2184.
If we want to manipulate in C++ threads created in C or vice versa, then we have pthread_t exposition problems which are the basically same problems as described for mutexes,
N2184 does expose a pthread_t under POSIX, see 'native_thread_handle'.
and in addition, we also have the join/cancel problems which were described elaborately by Howard.
An interoperability requirement for pthread_cancel doesn't make N2184 impossible, just infinitely more useful.
Peter Dimov wrote:
Yuval Ronen wrote:
Peter Dimov wrote:
Yuval Ronen wrote:
So to rephrase what I wanted to say in the most concise manner - the cost I was talking about is that the interoperability requirement makes N2184 impossible. As simple as that. I've no idea what you mean, sorry. What part of N2184 is impossible and why? It depends on what kind of interoperability we're talking about. If we want to manipulate in C++ mutexes created in C or vice versa, then the example from the previous post explains it.
There are no mutexes in N2184.
True, but N2184 is based on N2094 which does. Doesn't matter; the thread stuff is more interesting.
If we want to manipulate in C++ threads created in C or vice versa, then we have pthread_t exposition problems which are the basically same problems as described for mutexes,
N2184 does expose a pthread_t under POSIX, see 'native_thread_handle'.
Right. This goes under "how to manipulate in C, a thread created in C++", which is what I claimed to be a minor thing. The major problem is the other way around - how to manipulate in C++, a thread created in C.
and in addition, we also have the join/cancel problems which were described elaborately by Howard.
An interoperability requirement for pthread_cancel doesn't make N2184 impossible, just infinitely more useful.
In this area I know much less than you guys, but I have to say I find it very hard to imagine how such interoperability would look like. If I'm wrong and it really is possible, then that's good news for me :-)
Yuval Ronen wrote:
I never said that. If the C standard committee decides to fully adopt pthreads, I'd be fine with it. And if the C++ standard committee decides to be backwards compatible with C, and also adopt pthreads, I'd be fine with that too. I just don't think it should come instead of "the best" C++ interface, which is what I care about most.
Nobody can disagree with that. The problem in our discussion lies with tying whether one C++ API is better than another with whether the C++ API comes with a C API in the same proposal. This implies that the second C++ API contains design compromises purely because it has a C sibling - guilt by association - without actually stating any. Another interesting question is whether "the best" C++ interface is independent of the existence of a standard pthreads API. The answer very much depends on the perspective of whoever determines what is "best" for him, of course.
Peter Dimov wrote:
Yuval Ronen wrote:
I never said that. If the C standard committee decides to fully adopt pthreads, I'd be fine with it. And if the C++ standard committee decides to be backwards compatible with C, and also adopt pthreads, I'd be fine with that too. I just don't think it should come instead of "the best" C++ interface, which is what I care about most.
Nobody can disagree with that. The problem in our discussion lies with tying whether one C++ API is better than another with whether the C++ API comes with a C API in the same proposal. This implies that the second C++ API contains design compromises purely because it has a C sibling - guilt by association - without actually stating any.
The problem with bringing a C and C++ in the same proposal is that you tie them together, while they are not (providing I assume interoperability is not an issue, which is probably not agreed by everyone). It makes it hard, at least psychologically, at least for me, to accept one without the other, which is what I'm after. If this is really just a stupid misunderstanding on my part, then that makes things easier. In that specific case of N2178 the C++ part doesn't only come in the same paper as the C part, it depends on it, And vice versa, the C part is crafted to support this specific C++ part (the extended stuff). They are intertwined, which makes it even harder to separate them.
Yuval Ronen wrote:
Peter Dimov wrote:
Yuval Ronen wrote:
I never said that. If the C standard committee decides to fully adopt pthreads, I'd be fine with it. And if the C++ standard committee decides to be backwards compatible with C, and also adopt pthreads, I'd be fine with that too. I just don't think it should come instead of "the best" C++ interface, which is what I care about most.
Nobody can disagree with that. The problem in our discussion lies with tying whether one C++ API is better than another with whether the C++ API comes with a C API in the same proposal. This implies that the second C++ API contains design compromises purely because it has a C sibling - guilt by association - without actually stating any.
The problem with bringing a C and C++ in the same proposal is that you tie them together, while they are not (providing I assume interoperability is not an issue, which is probably not agreed by everyone). It makes it hard, at least psychologically, at least for me, to accept one without the other, which is what I'm after.
True. But as I said, someone had to do it (in my opinion). That is, make the assumption that the committee would like to accept an unified C/C++ proposal and proceed based on that. I do realize that this leads to a psychological penalty for the C++ part of N2178. My aim was to make sure that it doesn't lead to a design or efficiency penalty.
participants (5)
-
Emil Dotchevski -
Peter Dimov -
Richard Day -
Sohail Somani -
Yuval Ronen