From: Andrey Semashev (andysem_at_[hidden])
Date: 2006-12-19 13:25:02
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
>> 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
> 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
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
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_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk