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.