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-29 19:21:42

Stefan Strasser-2 wrote:
> 
> Am Sunday 29 November 2009 22:25:21 schrieb Vicente Botet Escriba:
>> Oliver Kowalke-2 wrote:
>> > I've uploaded a new version of boost.fiber - main features are:
>>
> 
> I haven't found it in the vault, is it still there?
> is the version in the sandbox the most current?
> 
>> I have a question. I understand we need fibers::mutex and
>> fibers::condition_variable, but could you explain why do we need a
>> separated fibers::lock_guard and fibers::unique_lock template classes?
>> Why
>> the ones from Boost.Thread are not usable in the fiber context, at the
>> end
>> the Mutex parameter can be any model of lockable?
> 
> the mutexes are also almost independent of fibers, aren't they?
> they are CAS-based mutexes that could be used with threads as well, except
> for 
> the call to this_fiber::yield().
> CAS-based mutexes are long overdue for Boost.Thread. (I've even used
> random 
> mutex sharing just to avoid the 24 bytes overhead a pthreads mutex is
> worth, 
> for something that's basically a CAS-protected bool). so a mutex template 
> with a parameter on what to do to waste some time (this_fiber::yield, 
> this_thread::yield, spinning...) could clean this up.
> Boost.Interprocess also has its share of mutexes AND its own 
> scoped_lock/shared_lock/upgrade_lock.
> 
> it doesn't make much sense to have seperate synchronization code for 
> Processes, Threads and Fibers.
> (with some exceptions, like named mutexes in Boost:Interprocess)
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 

Hi,

I suppose the version on the vault is the stable one, and the one on the
sandbox the ongoing version.

I know Interprocess has  its share of mutexes AND its own
scoped_lock/shared_lock/upgrade_lock. 
I was warming Oliver exactly for this reason, to avoid other family of
locks.

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.

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