[thread library rework] Ready to start
Hi to all, As previously discussed here, I'm trying to organize a boost thread rework in order to help C++ thread standarization. In this moment, Kevlin Henney is working on a paper to be presented int the next ISO meeting based in his C++ thread work which is available here, in this presentation-paper: http://www.two-sdg.demon.co.uk/curbralan/papers/accu/MoreC++Threading.pdf This approach proposes futures approach to C++ threads, and also defines lock mechanisms similar to boost::mutex and boost::condition with some changes. I've contacted with Kevlin and he is ready to help as much as he can with the Boost community to develop a good thread proposal. The idea is that we could have a working implementation of the proposal above boost threads. The presentation-paper does not currently cover all the functionality we have, like thread specific storage, barriers and read-write locks neither proposed message-queue, so there is a lot of work to do. There is an active discussion on futures that can be added to this effort since it proposes future-operations that are not incompatible with the proposal, but an extension. We need to keep the thread discussion constructive and effective, although any of us has strong opinions on threading. It would be nice if we could first concentrate in "basic" functionality that does not forbid future proposals. For example, thread cancellation is a hard issue, but it can be added later if the proposal allows to do that. I'm also concerned with (in my opinion) needed compatibility with Embedded C++. C++ will grow a lot in this area and obviously, threads are very used. Embedded C++ specification (http://www.caravan.net/ec2plus/) avoids templates and exceptions, so we need to think some alternatives (apart from exceptions, just like iostreams do) to do error checking. And provide some low-resource specializations or alternatives to the full-scale C++ threading. There are many areas to cover, but in this post I would like to say that the reworking effort is alive and we need to do some serious work. Like always, ideas are good but work is better, so let's try to avoid extremely long discussions so that we can have C++ threads in the following standard. I'm ready to try to organize a bit the effort and Michael Glassford, mantainer of boost threads, is ready to help, although he has no much time. Anyway, we know there are some good thread implementations out there, and we can take some ideas. And let's try to create a basic, simple, working thread tools but without forbidding extensions in the future. For the moment I've implemented the thread-launching mechanism (threader and joiner classes) described in Kevlin's paper above boost threads. It's in Boost Vault, in thread_ex directory. I plan to add more features detailed in the paper soon (mutexes, conditions, etc...) above boost threads, because it provides a good portable framework. Currently there is no other documentation that Kevlin's presentation, but I will start making some boost documentation in this library, once we start defining more elements. I will try to write some posts regarding concrete issues, like barriers, read-write mutexes or message-queues so that we can focus the work. Obviously if anyone wants to join this effort with ideas, code, organization etc... we can split the work on several issues. Regards, Ion P.D.: I plan to continue Shmem development although, I will have less time to work on it because of this threading work. I plan to upload a new snapshot soon.
For the moment I've implemented the thread-launching mechanism (threader and joiner classes) described in Kevlin's paper above boost threads. It's in Boost Vault, in thread_ex directory.
Ooops, I've uploaded the wrong version. New version uploaded, this one compiles with gcc and has a test Jamfile. Regards, Ion
On 8/26/05, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Hi to all,
Hello, [snip]
I'm also concerned with (in my opinion) needed compatibility with Embedded C++. C++ will grow a lot in this area and obviously, threads are very used. Embedded C++ specification (http://www.caravan.net/ec2plus/) avoids templates and exceptions, so we need to think some alternatives (apart from exceptions, just like iostreams do) to do error checking. And provide some low-resource specializations or alternatives to the full-scale C++ threading.
I dont that the embedded C++ should be a concern. It is just a too small subset of C++, that I think would avoid better solutions for "backward"(since I think EC++ is a step back) compatibility. I even agree with Bjarne Stroustrup FAQ about EC++: http://www.research.att.com/~bs/bs_faq.html#EC++
Regards,
good work.
Ion
P.D.: I plan to continue Shmem development although, I will have less time to work on it because of this threading work. I plan to upload a new snapshot soon.
I hadnt time to see Shmem yet, but I'm trying to find some time to take a look at it. It really seems interesting and is certainly very useful. best regards, -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Ion Gaztañaga <igaztanaga@gmail.com> writes:
I'm also concerned with (in my opinion) needed compatibility with Embedded C++. C++ will grow a lot in this area and obviously, threads are very used. Embedded C++ specification (http://www.caravan.net/ec2plus/) avoids templates and exceptions,
They were wrong to do so, most especially for templates, which are hugely useful in embedded programming.
so we need to think some alternatives (apart from exceptions, just like iostreams do) to do error checking. And provide some low-resource specializations or alternatives to the full-scale C++ threading.
In my opinion, that would be a huge mistake. EC++ was created as a "language subset" without the consent or cooperation of the C++ committee. Crippling C++ library interfaces simply in order to maintain compatibility with it is the wrong thing to do, again IMO. -- Dave Abrahams Boost Consulting www.boost-consulting.com
* David Abrahams (dave@boost-consulting.com) [20050829 14:15]:
They were wrong to do so, most especially for templates, which are hugely useful in embedded programming.
What do you expect of library vendors that want to sell their implementation? There were fears that certain C++ features would make it less useful for embedded developers (be it memory bloat or what else) so they came up with EC++, which helped them sell to the embedded world. It was always funny to see pjp and the dinkum folks defending EC++ on comp.languages.c++ :) Philipp
What do you expect of library vendors that want to sell their implementation? There were fears that certain C++ features would make it less useful for embedded developers (be it memory bloat or what else) so they came up with EC++, which helped them sell to the embedded world.
It was always funny to see pjp and the dinkum folks defending EC++ on comp.languages.c++ :)
I didn't know that EC++ was created without C++ comittee consensus, but I think achieving a well-defined subset of C++ is good for C++. This involves analizing performance aspects of C++ and can push C++ forward. This happens in C and other languages. Obviously you can argue that this is only to sell libraries, but as a embedded developer I don't see any problem in defining a subset for embedded systems because C++ is very extense. Obviously, it would be better to count with C++ comittee. I didn't want to start a war regarding EC++, so I maybe I should start talking about "embedded" instead. Regards, Ion
Ion Gaztañaga <igaztanaga@gmail.com> writes:
What do you expect of library vendors that want to sell their implementation? There were fears that certain C++ features would make it less useful for embedded developers (be it memory bloat or what else) so they came up with EC++, which helped them sell to the embedded world.
It was always funny to see pjp and the dinkum folks defending EC++ on comp.languages.c++ :)
I didn't know that EC++ was created without C++ comittee consensus, but I think achieving a well-defined subset of C++ is good for C++.
Why?
This involves analizing performance aspects of C++ and can push C++ forward.
How?
This happens in C and other languages.
Example, please?
Obviously you can argue that this is only to sell libraries, but as a embedded developer I don't see any problem in defining a subset for embedded systems because C++ is very extense.
There are good arguments against subsetting; it tends to weaken the standard.
Obviously, it would be better to count with C++ comittee.
I didn't want to start a war regarding EC++, so I maybe I should start talking about "embedded" instead.
Maybe. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Philipp Thomas <pth@suse.de> writes:
* David Abrahams (dave@boost-consulting.com) [20050829 14:15]:
They were wrong to do so, most especially for templates, which are hugely useful in embedded programming.
What do you expect of library vendors that want to sell their implementation?
I don't understand the question. -- Dave Abrahams Boost Consulting www.boost-consulting.com
They were wrong to do so, most especially for templates, which are hugely useful in embedded programming.
I agree with you in templates, if you take care with code bloating.
In my opinion, that would be a huge mistake. EC++ was created as a "language subset" without the consent or cooperation of the C++ committee. Crippling C++ library interfaces simply in order to maintain compatibility with it is the wrong thing to do, again IMO.
Well, I'm not talking about EC++ but embedded world in general. In my work I program for embedded systems everyday in C and C++ and threading, in my opinion, is a very basic building block for embedded systems, so if we want to put C++ in those systems just like we can do with C (you don't pay for what you don't use) we should have a way to launch a thread in a standard way in limited systems. Exception system has a size overhead (well, that depends, but if you have 512KB-1MB of RAM...) and in most systems RTTI and exceptions are disabled to save space. Exceptions are also not recommended in real-time systems, and you can use threads and mutexes. As an example, in iostreams, you can activate or not exceptions. Not that I think we must limit C++ because of EC++, but that we should think that a very important C++ market (growing nowadays) will be embedded/realtime systems, replacing many C applications, because productivity in C++ is higher and you can get nearly C performance. And again IMO, threads are too basic. I would never say this for regular expressions, serialization, or any other library. If we can't do anything about that, that's ok, but why not try? I agree that it is hard to get, but that's the beauty of C++, you can put it everywhere, from tiny devices to mainframes. And I think that Kevlin's approach can be safely used in embedded systems if we see that it's easy to get a subset of the full standard, using the same programming style (for example, futures). It's not that I love EC++ (I don't follow its guidelines, because I use templates in some embedded systems), it's that I see a practical need to take in care those aspects. If C can have it, C++ can. I'm not saying I would sacrifice C++ for embedded world, but it is better to take in care aspects so that we can spread C++ further. Best wishes, and regards, Ion (embedded warrior)
Ion Gaztañaga <igaztanaga@gmail.com> writes:
They were wrong to do so, most especially for templates, which are hugely useful in embedded programming.
I agree with you in templates, if you take care with code bloating.
Bah. Templates can just as easily reduce code bloat. http://groups.google.com/group/comp.lang.c++.moderated/msg/82674634c2a6b3a0 http://groups.google.com/group/comp.lang.c++.moderated/msg/2efe6b65b0e51a4f
In my opinion, that would be a huge mistake. EC++ was created as a "language subset" without the consent or cooperation of the C++ committee. Crippling C++ library interfaces simply in order to maintain compatibility with it is the wrong thing to do, again IMO.
Well, I'm not talking about EC++ but embedded world in general. In my work I program for embedded systems everyday in C and C++ and threading, in my opinion, is a very basic building block for embedded systems, so if we want to put C++ in those systems just like we can do with C (you don't pay for what you don't use) we should have a way to launch a thread in a standard way in limited systems.
I agree.
Exception system has a size overhead (well, that depends, but if you have 512KB-1MB of RAM...) and in most systems RTTI and exceptions ^ embedded are disabled to save space.
I wonder how much space gets spent on error handling without exceptions, and I wonder if the error handling is correct.
Exceptions are also not recommended in real-time systems, and you can use threads and mutexes. As an example, in iostreams, you can activate or not exceptions.
I know.
Not that I think we must limit C++ because of EC++, but that we should think that a very important C++ market (growing nowadays) will be embedded/realtime systems, replacing many C applications, because productivity in C++ is higher and you can get nearly C performance.
IMO it is crucial to engage compiler developers for embedded systems in optimizing their runtimes for those environments. http://groups.google.com/group/comp.lang.c++.moderated/msg/d37971376bfd7e09?... However I agree as a practical matter there should be an obvious way to implementat Boost.Threads that works on a system with exceptions disabled.
And again IMO, threads are too basic. I would never say this for regular expressions, serialization, or any other library. If we can't do anything about that, that's ok, but why not try? I agree that it is hard to get, but that's the beauty of C++, you can put it everywhere, from tiny devices to mainframes. And I think that Kevlin's approach can be safely used in embedded systems if we see that it's easy to get a subset of the full standard, using the same programming style (for example, futures).
It's not that I love EC++ (I don't follow its guidelines, because I use templates in some embedded systems), it's that I see a practical need to take in care those aspects. If C can have it, C++ can. I'm not saying I would sacrifice C++ for embedded world, but it is better to take in care aspects so that we can spread C++ further.
Agreed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Felipe Magno de Almeida -
Ion Gaztañaga -
Philipp Thomas