I've been trying to figure out exactly what EE_HYBRID does. I've looked at the wiki and I've looked in TransactionConflictManager.C, but I don't get it. (Actually, I can't find anything described in TransactionConflictManager.C, there's only one reference to HYBRID in the whole file, and it does the same thing as TIMESTAMP.) Anyway here's my guess, let me know if it's right.
TIMESTAMP will kill the younger transaction in any conflict. HYBRID will allow the younger transaction to live iff the value in conflict is ONLY in the younger transaction's write set. In other words, if the younger transaction read or read and modified the conflicting value, it is kill, but if the younger transaction only wrote the value, the younger transaction is stalled until the older transaction commits.
Maybe?
Thanks, Jim
On Sun, Mar 9, 2008 at 2:27 PM, Jayaram Bobba < bobba@xxxxxxxxxxx> wrote:
$GEMS/ruby/log_tm/TransactionConflictManager.C gives a more precise
description of the conflict resolution policies
than the wiki.
The conflict resolution policies used in the pathologies paper:
EE - BASE and HYBRID
EL - BASE and TIMESTAMP
LL - BASE
The XACT_NO_BACKOFF parameter determines if software backoff is used
along with any particular policy. Look at
gen-scripts.py to see which policies use this parameter.
Jayaram
Jim Leek wrote:
> In the Pathologies paper it gives a set of the different kinds of
> Transactional memory styles, and they have different conflict
> resolution methods. LL is committer wins, EL is Requester wins, and
> EE is requester stalls. However, I don't really see these options in
> rubyconfig.defaults. This is what the wiki says:
>
> *XACT_EAGER_CD*: (true or false) Setting to true enables eager
> conflict detection. Otherwise uses lazy conflict detection.
>
> *XACT_LAZY_VM*: (true or false) Setting to true enables lazy version
> management via an infinite write buffer. Otherwise uses eager version
> management. *Must also set XACT_MEMORY to true during protocol
> compilation, or else appropriate Simics callbacks will not get registered.
>
> **XACT_CONFLICT_RES*: (BASE, TIMESTAMP, HYBRID, or CYCLE) Different
> policies of conflict resolution. BASE aborts the requestor whenever
> there's a conflict. TIMESTAMP aborts a requestor only if the requestor
> is younger than the conflicting processor. HYBRID aborts a younger
> transaction in favor of an older requesting transaction if the younger
> has the conflicting block in its read set only. CYCLE always indicates
> a conflict with other transactions, and is used to immediately trap to
> a software contention manager.
>
> so, if I use EE-base, does requester stall? EL's policy of requester
> always wins doesn't even seem to be an option? (I'm guessing that
> EL-base actually does this.)
>
> Thanks,
> Jim
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
>
>
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.
|