Boost logo

Boost :

From: Andrey Semashev (andysem_at_[hidden])
Date: 2006-12-19 13:25:02

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

> 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, gregod at, cpdaniel at, john at