Boost logo

Boost :

From: george (george13p_at_[hidden])
Date: 2006-04-03 17:11:52

> On Sunday 02 April 2006 22:25, george wrote:
> > boost::mutex mutex;
> > boost::detail::atomic_count locked;
> [...]
> > bool someclass::a_writer(.....)
> > {
> > boost::mutex::scoped_lock scoped_lock(mutex,true);
> [point 1]
> > ++locked;
> [...]
> > --locked;
> > return false;
> > }
> Note here: if a different thread is scheduled at point 1, it will not see that
> 'locked' will be incremented, only the locked mutex.

yes,it's risky.....

> > bool someclass::a_reader(.....)
> > {
> > boost::mutex::scoped_lock scoped_lock(mutex,(locked!=0));
> Here, if 'locked' is not zero, you acquire the mutex. Well, to be more
> precise, you acquire the mutex if at some -albeit short ago- time in the past
> 'locked' was not zero. You don't acquire it if at some equally long time in
> the past it was zero. You have no idea about whether it is zero now.

yes,I acquire the lock when and only when the locked==0,the time I check for
it...offcourse a shoooort time after it may be changed by a writer and here is a
problem........but there is 3 things :
    a)The readers method is non-blocking,in memory searching in std::map,very fast
    b)writer method will be used very rare,every 24hrs
    c)I don't sugest this technik in general,just for this case,almost read only

I just post this code becouse I wanted boost developers opinion about
what I am doing and get response from if they had did anything similar.

> > I wanna combine atomic_count and scope locking so I can avoid locking on
> > every operation.
> Hmm, what you want is a read-write lock, it seems.

there is no read-write lock anymore in boost-thread :-(
read-write lock are very expensive and in my case would be worse....

> > I know that what I am doing is not recommended,atomic_count.hpp is for
> > internal use only, but is so usefull!
> Formalising and exporting atomic integer operations was requested before, +1
> to the number of votes for that, or rather +2 if I may give my vote. I think
> this has already been scheduled to after the rewrite of Boost.Threads though.

I am happy to hear this:)


Boost list run by bdawes at, gregod at, cpdaniel at, john at