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