Boost logo

Boost :

Subject: Re: [boost] [transact] code in sandbox
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-02-17 06:28:04


strasser wrote:
>
> 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:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
>

You can start with
Extending Contention Managers for User-Defined Priority Based Transactions
from http://eces.colorado.edu/~gottschl/tboostSTM/pubs.html

Let me know if you don't find the response there.

Best,
Vicente

-- 
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, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk