strasser wrote:
Zitat von "vicente.botet" <vicente.botet@wanadoo.fr>:
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.