[thread] Proposal to add lightweight_mutex and atomic_count
Hello, There are "lightweight_mutex.hpp" and "atomic_count.hpp" files in the "detail" directory. I find these tools quite simple and useful in some projects where I don't want to link against the whole Boost.Thread library yet having a degree of portability. But every time I include it the nasty "detail" word in the path always makes me remember that I'm using library's internals that are not the part of public interface. Why not making these tools a part of Boost.Thread library, without any change, of course? A couple of forwarding headers in "boost/thread" and a documentation update would be a nice solution. Thank you. -- Best regards, Andrey mailto:andysem@mail.ru
Andrey Semashev wrote:
There are "lightweight_mutex.hpp" and "atomic_count.hpp" files in the "detail" directory. I find these tools quite simple and useful in some projects where I don't want to link against the whole Boost.Thread library yet having a degree of portability. But every time I include it the nasty "detail" word in the path always makes me remember that I'm using library's internals that are not the part of public interface.
Why not making these tools a part of Boost.Thread library, without any change, of course? A couple of forwarding headers in "boost/thread" and a documentation update would be a nice solution. Thank you.
Because it is a not so simple task to solve the atomic issue in general. Altough there is ongoing work in the C++ standardization process. I am currently trying to keep in touch with these proposals an prepare a library submission. Then the lighweight_mutex is not so much different from what will be available in the next release of the threading lib. I think it already is not so much different from the current implementation. Do you see this differently? If yes why? The atomic thing on the other hand is hard to get platform independent, because it strongly depends on the MP architecture. Roland
Hello Roland, Tuesday, December 19, 2006, 3:07:18 AM, you wrote:
Andrey Semashev wrote:
There are "lightweight_mutex.hpp" and "atomic_count.hpp" files in the "detail" directory. I find these tools quite simple and useful in some projects where I don't want to link against the whole Boost.Thread library yet having a degree of portability. But every time I include it the nasty "detail" word in the path always makes me remember that I'm using library's internals that are not the part of public interface.
Why not making these tools a part of Boost.Thread library, without any change, of course? A couple of forwarding headers in "boost/thread" and a documentation update would be a nice solution. Thank you.
Because it is a not so simple task to solve the atomic issue in general.
But it is solved in those tools, isn't it? Lightweight mutex and atomic_count already have support for most commonly used threading APIs.
Altough there is ongoing work in the C++ standardization process. I am currently trying to keep in touch with these proposals an prepare a library submission.
Then the lighweight_mutex is not so much different from what will be available in the next release of the threading lib. I think it already is not so much different from the current implementation. Do you see this differently? If yes why?
The main difference is that I need to build Boost.Thread to use its implementation. In case if I'm developing my own header-only library that is aware of threading, the need to link against something is undesirable. Is the new version of the library available to see? Do I understand you correctly in that there will be no need to link against a library (static or dynamic) while using a basic mutex model in the new lib?
The atomic thing on the other hand is hard to get platform independent, because it strongly depends on the MP architecture.
Well, I can't disagree. That's why I like atomic_count so much. Some parts of atomic code may also be found in shared_ptr implementation (see sp_counted*.hpp files). If some exotic platform is not covered with atomic_count we may take that code to support that platform. Actually, I come to thinking that it would be good to gather these atomic tools in a public library - Boost.Thread or another one, though the Thread library would be a more convenient place. -- Best regards, Andrey mailto:andysem@mail.ru
Andrey Semashev <andysem@mail.ru> writes:
Tuesday, December 19, 2006, 3:07:18 AM, you wrote:
Andrey Semashev wrote:
There are "lightweight_mutex.hpp" and "atomic_count.hpp" files in the "detail" directory. I find these tools quite simple and useful in some projects where I don't want to link against the whole Boost.Thread library yet having a degree of portability. But every time I include it the nasty "detail" word in the path always makes me remember that I'm using library's internals that are not the part of public interface.
Why not making these tools a part of Boost.Thread library, without any change, of course? A couple of forwarding headers in "boost/thread" and a documentation update would be a nice solution. Thank you.
Because it is a not so simple task to solve the atomic issue in general.
But it is solved in those tools, isn't it? Lightweight mutex and atomic_count already have support for most commonly used threading APIs.
The atomic_count support for pthreads is rather basic --- it just wraps a mutex with the value, and locks the mutex for every access. The sp_counted_base supports more platforms in that regard, but the atomic stuff is intertwined with shared_ptr-specific stuff.
Then the lighweight_mutex is not so much different from what will be available in the next release of the threading lib. I think it already is not so much different from the current implementation. Do you see this differently? If yes why?
The main difference is that I need to build Boost.Thread to use its implementation. In case if I'm developing my own header-only library that is aware of threading, the need to link against something is undesirable.
I'm hoping that much of the new Boost.Thread library will be header-only, but that may not be achievable.
Is the new version of the library available to see? Do I understand you correctly in that there will be no need to link against a library (static or dynamic) while using a basic mutex model in the new lib?
The new version is under development on the thread_rewrite branch of boost CVS. Be aware that neither the interface, or implementation are set in stone as yet.
Actually, I come to thinking that it would be good to gather these atomic tools in a public library - Boost.Thread or another one, though the Thread library would be a more convenient place.
Agreed. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
participants (3)
-
Andrey Semashev -
Anthony Williams -
Roland Schwarz