Re: [boost] using boost/detail/atomic_count.hpp and scope locking

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

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

thanks.