Deuce 1.1 is out !

8 views
Skip to first unread message

Guy Korland

unread,
Oct 17, 2009, 6:20:28 PM10/17/09
to Deuce-STM developers
Deuce 1.1 if finally out after few delays. It can be downloaded from
the Download page.
Thanks for the team work and the feedback we got which helped us find
many critical bugs before this final version.

This version includes:
1. Full offline instrumentation, for more detail see the Documentation
page.
2. Add a new transaction implementation LSACM, which is a new version
of LSA with a contention manager.
To use this new implementation set -
Dorg.deuce.transaction.contextClass=org.deuce.transaction.lsacm.Context
3. Few minor bug fixes.

Adam

unread,
Oct 27, 2009, 1:09:02 PM10/27/09
to Deuce-STM developers
I was wondering what the difference between the lsa and lsacm
algorithms is. I do understand that the former does not use a
contention manager whereas the latter does, but are there any other
differences beyond the ability to experiment with different contention
managers in case of lascm? For example, I noticed that lsacm uses
"synchronized" blocks in its transactional barrier implementation
(btw. - wouldn't using locks from java.util.concurrent package be more
efficient?). Does it have any impact on the performance of lsa - does
one of the variants perform/scale better than the other? It's
difficult for me to believe inclusion of "synchronized" blocks has no
impact on performance but I couldn't find any comments on the issue.

Thank you

Adam

Pascal Felber

unread,
Oct 27, 2009, 1:56:32 PM10/27/09
to deuce-stm-...@googlegroups.com
Hi,

lsacm will most often be less efficient than lsa or tl2 for workloads
with little contention. Upon conflict, lsa and tl2 will systematically
abort the transaction that discovers the conflict; this simple
contention management strategy does not provide liveness guarantees
and may produce livelocks in some pathological scenarios. What lsacm
does is allow developers to specify their own contention managers and
decide upon conflict whether to abort (1) the transaction that
discovers the conflict, or (2) the transaction that currently owns the
lock. Having this flexibility comes with an overhead at runtime.
Please consider lsacm as experimental at this time. It has not been as
well tested as lsa and tl2, and it can certainly be optimized further.
Synchronized blocks have been used to simplify the implementation of
the first version, but they can be replaced by more efficient
alternatives.

Cheers,

Pascal
Reply all
Reply to author
Forward
0 new messages