Hi, everyone:
I
have few questions on LogTM protocol during reading the source:
1. The first question is about transaction abort processing. Within my
understanding from the source, during the aborting process, transaction manager
restore memory value from transaction log, clear the R, W, L, T bits in
LogTMCache entry. But the manager does not restore the coherence state of the cache
entry that was previously opened during the transaction, i.e., if the cache
entry's state is in "transaction shared", after aborting, it changed
to "Shared" and transactional write entry with state “transaction
modified” will be changed to “Modified” because the manager only
clears the flag bits. I think it would be reasonable to remove these cache entries
of state “transactional write” and make directory state to “sticky_m”,
or restore the entry’s value when performing the restore from transaction
log (not acceptable in real hardware implementation); otherwise it would be incorrect
if the processor reloads the block neither in and out of transaction. Maybe I missed
some point in the source, can anybody shows if there exists such problem?
2. I have found that there are some directory states (IMO, SMO, and OMO)
that have no entrance point. Are these states necessary? And the corresponding transition
will ever be reached?
3. For the following transition items, I can not think out a message sequence
that will research the transition, can anybody give me some hints?
1) transition(OS,
Unblock, O) {
j_popIncomingUnblockQueue;
}
2) transition({OO,
OOM}, Unblock_Nack) {
o_decrementOutstanding;
//oo_checkForCompletion;
j_popIncomingUnblockQueue;
}
3) transition(IM,
{Unblock_Nack, Last_Unblock_Nack}, I) {
//
this should only happen when
//
a transaction aborts and yields
//
an exclusive lock.
j_popIncomingUnblockQueue;
}
For
this transition, I do not really understand the comments; can give me a more detailed
explanation?
Thanks very much for reading my question.