dcapwell commented on code in PR #136:
URL: https://github.com/apache/cassandra-accord/pull/136#discussion_r1833507308
##########
accord-core/src/main/java/accord/impl/AbstractConfigurationService.java:
##########
@@ -74,38 +78,57 @@ public String toString()
}
/**
- * Access needs to be synchronized by the parent ConfigurationService class
+ * Thread safety is managed by a synchronized lock on this object, and
extending classes can use the same lock when needed.
+ *
+ * There is a special case when the last recieved/acknowleged epochs are
needed, they can be accessed without a lock
+ * and provide a happens-before relationship (if lastReceived=42, epoch 42
exists and is set up)
*/
@VisibleForTesting
public abstract static class AbstractEpochHistory<EpochState extends
AbstractEpochState>
{
// TODO (low priority): move pendingEpochs / FetchTopology into here?
private List<EpochState> epochs = new ArrayList<>();
- protected long lastReceived = 0;
- protected long lastAcknowledged = 0;
+ /**
+ * {@link #lastReceived} and {@link #lastAcknowledged} help define the
visibility by making sure that the update is the very last thing done in their
respected logic.
+ * This means that the read of these fields can be done without a lock
and can be used to tell the caller that the given epoch has reached a given
step.
Review Comment:
This semantic was to simplify
`accord.impl.AbstractConfigurationService#reportTopology(accord.topology.Topology,
boolean, boolean)` to avoid making changes.
`lastReceived` and `lastAcknowledged` are accessed to see if we need to
enqueue on `epoch - 1` or if we can receive right away. To avoid extra locking
went with a volatile read at the start of the method and receive/ack do the
volatile write at the end to publish. `receive` and `receiveFuture` both lock
on the epochs, which makes the area of the lock just those 2 methods
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
