Enhancing APCu Lock Efficiency (for ChainedFast for High-Concurrency Cache Invalidation)

Here is the ChatGPT analysis of this function:

You’ve highlighted an important aspect of how these APCu functions interact with the underlying data store, and you are correct in your understanding of the different lock mechanisms they employ.

### apcu_cas()

- `apcu_cas()` operates with a lighter locking mechanism.
- It only requires a reader lock on the entry.
- It performs a compare-and-swap (CAS) operation, which is atomic.
- This means that it can check the current value and, if it matches the expected value, update it in a single atomic operation.
- Because it only needs a reader lock, it doesn't block other reads from happening simultaneously.

### apcu_store()

- On the other hand, `apcu_store()` requires a writer lock.
- A writer lock is more restrictive; it blocks both other writers and readers until the operation is complete.
- This can lead to longer wait times and potential bottlenecks, especially under high load or when dealing with large data sets.

### Why Your Approach Is Beneficial

- By initializing the lock with `apcu_add()` (which uses `apcu_store()` internally but is only called once at the start), and then using `apcu_cas()` for subsequent lock acquisitions, you ensure that the heavier writer lock is acquired less frequently.
- Most of the synchronization relies on `apcu_cas()`, which uses the lighter reader lock, resulting in less contention and better performance.
- This is especially beneficial in a high-concurrency environment, where many processes are trying to acquire the lock simultaneously.

By understanding and leveraging the underlying mechanisms of these APCu functions, your approach efficiently reduces lock contention, leading to better performance and scalability. This kind of optimization is crucial in performance-critical applications and high-load scenarios.

As background reading.

+1 to CAS

  // Attempt to acquire the lock.
  if (apcu_cas($lock_key, $old_lock_value, $lock_value)) {
    $this->setWithoutLock($cid, $data, $expire, $tags);
  }

If this is false, what should happen? Do we assume it got set with the correct value already and silently skip it?

#9: If this is false, what should happen? Do we assume it got set with the correct value already and silently skip it?

If this is false, then another process has gotten the "lock" and either calls setWithoutLock() right now, has called setWithoutLock() already or will call setWithoutLock() in the near future.

As this is just about avoiding write stampedes to the same item (first step), there is likely even a process that is still before the apcu_fetch() and will write the data again, so we also don't need to worry about the process that got the "lock" to crash.

Someone else will then set it.

OK I think we should add a comment explaining this in the future MR, but that sounds right to me. We just have to assume that apcu_cas() can't get into a permanent failure state, but then if it does, it's probably because apcu as a whole is so writes wouldn't work anyway.

you need to loop the two random number generations until they are not equal

Is there plan how to test it?
Looks it does not work for Novice tag

I bet it needs to improve tests and profiling too