From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-12-20 04:21:50
Andrey Semashev <andysem_at_[hidden]> 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
>>> 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
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
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
> 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.
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk