// Unlike the other types, unlock is always a nop. It makes sense for the schedular or any other caller to not automatically reset an event, contrary to `::Lock(); work; ::Unlock();`
// Ordinarily, we would expect the thread responsible for dispatching work to Unlock, and the caller Reset, at least in principle. This, however, does not account for reusability.
// It makes sense to implement reset-on-worker-acknowledge, permit-multiple-triggers (a kind of countless semaphores), and any combination thereof
// Besides from atomicRelease, Reset and Set is on your watch.