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.