Re: [boost] [fiber] new version in vault

Subject: Re: [boost] [fiber] new version in vault
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2009-11-30 08:57:33

Stefan Strasser-2 wrote:
> 
> Am Monday 30 November 2009 01:21:42 schrieb Vicente Botet Escriba:
> 
>> For the mutexes is another history. Have you tried to make a mutex class
>> that works for process, threads and fibers? If you did, I'm interested in
>> seen how you have reached that.
> 
> no I have not, but if you look at...
> 
> https://svn.boost.org/svn/boost/sandbox/fiber/libs/fiber/src/mutex.cpp
> 
> ...Oliver almost has.
> 
> slightly changed to:
> 
> namespace sync{
> 
> template<class Suspend>
> struct basic_cas_mutex{
>   void lock(){
>     while(true){
>       uint32_t expected = 0;
>       if ( detail::atomic_compare_exchange_strong( & state_, & expected,
> 1) )
>         break;
>       else
>         Suspend()();
>     }
>   }
>   ...
>   ...
> };
> 
> <snip>
> 
> 

Hi,

I like your sync::basic_cas_mutex class template, how it can be used on a
thread or fiber context or even to build a spin lock. Anyway you will have
two classes fiber::mutex and thread::mutex with a common implementation. Can
sync::basic_cas_mutex be used to protect inter-process concurrent access?

My concern was that we can and should use the same boost::lock_guard and
boost::unique_lock even when we have several implementations of Lockables. 

In addition, I don't think that we can say
sync::basic_cas_mutex<thread::suspend> could be equivalent to boost:mutex as
the following let think. 

> #if CAS supported on platform
> typedef sync::basic_cas_mutex<suspend> mutex;
> #else
> typedef sync::native_mutex mutex;
> #endif
> 
Both are useful on different context and should be provided separately. Up
to the user to choose the one adapted to its context.

Best,
Vicente
-- 
View this message in context: http://old.nabble.com/-fiber--new-version-in-vault-tp26557494p26575154.html
Sent from the Boost - Dev mailing list archive at Nabble.com.