Re: [boost] [thread] Proposal to add lightweight_mutex and atomic_count

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
>>> 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