Subject: Re: [boost] [transact] code in sandbox
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-02-17 06:28:04
> Zitat von "vicente.botet" <vicente.botet_at_[hidden]>:
>> The mix of optimistic and pessimistic strategies needs a careful design.
> could you explain what the difference is wrt Boost.Transact?
> whether there is an optimistic conflict or a pessimistic deadlock, the
> solution is retry.
>> We need to consider how contention management helps to avoid
>> starvation with optimistic synchronization. Transaction priorities
>> could be a way, other need to be considered, and see if the
>> interface is enough open to let the user choose its contention
>> management strategy.
> could you point me to a good introduction on that issue?
> I always assumed low-contention and conflicts being the exception,
> which I think is a valid assumption for persistent objects, but not
> necessarily for transactional memory.
> in one example using your macros the priority of a transaction was
> increased on contention. I don't understand how that helps when two or
> more threads contend about a resource. the priority of all threads
> would increase.
> Unsubscribe & other changes:
You can start with
Extending Contention Managers for User-Defined Priority Based Transactions
Let me know if you don't find the response there.
-- View this message in context: http://old.nabble.com/-transact--code-in-sandbox-tp27515535p27622298.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk