Argthtjtr

How understandable a program is often stands or falls with the correct choice of class and variable names; so this is really important to me.

I am designing a system where different threads do "requests" for an update of the "state" of a (sub)system. The requests are actually done in two steps: first a thread calls a method on a common object that then writes to a wrapped atomic int (aka, the "request" is really just some integer value). Then that same thread will continue with trying to synchronize the (sub)system with the requested state that it just wrote - this takes considerably more time of course. It is possible that before the thread gets to the synchronizing part another thread already replaced the request with a different one. In that case the first thread doesn't have to do anything (so the request was replaced, or superseded and became obsolete). The normal flow will be where almost every requests is handled, but it might happen that one is skipped because it was replaced before it could be handled thus.

I need names for three classes:

1) A class for objects that describe the (sub)system state (these will both, wrap the atomic int as well as keep track of what the last requester was).
2) A class for objects that describe a state that is being transported; this is a copy of the above atomic (it is therefore fuzzy; immediately after copying the atomic, the value might already be invalidated).
3) A class for objects that mark the begin and end area in which the above copy is made (acquired is the right word here), and transported to a critical area inside another function where it will be either handled or discarded.

Possible words would be 1) StateTracker, 2) StateTransport, 3) TransportLock. However, this doesn't capture the superseding nature, I find the word 'state' too general (I'm using it already so much) and the 'Tracker' side is really something internal, nothing to bother the user with (I'd rather just call it 'State').

I think a good way to proceed is to think of something physical and then name the classes after that model. The system kinda looks like a queue with a size of one (immediate replacement / discarding all predecessors). Ie, normally something would be placed in the "queue" (or on a small table) and then taken from there; but sometimes it would still be in the queue / on the table while a new object is placed there and just be lost.