Challenge 2: Why kvstore Isn't Safe for Concurrent Instances — Possible Solution
====================================================================

Two separately-run instances of kvstore, each executing a command
against the same kvstore.db file at roughly the same time, are
effectively two independent processes performing an unsynchronized
read-modify-write sequence against a single shared file -- structurally
the exact same shape of problem as c3-3's own shared-counter race
condition, just at the level of a file instead of an in-memory
variable. Each instance loads the file's current contents into its own
in-memory HashTable at startup, makes its own change (a set/get/delete),
and then calls save_to_file to rewrite the ENTIRE file based on its own
in-memory snapshot.

Concretely, what breaks: if instance A loads the file, then instance B
also loads the file (still seeing the same original state, since A
hasn't saved yet), and then A finishes its change and saves, and only
afterward B finishes ITS change and saves -- B's save completely
OVERWRITES the whole file with B's own in-memory snapshot, which never
included A's change at all. A's update is silently lost, with no error
or warning from either instance -- exactly the "one thread's update
gets silently clobbered by another's write" failure mode c3-3
described for the unsynchronized counter, just now happening to a
file's full contents on every save rather than a single integer on
every increment.

The specific chapter's material that would fix this: c3-3
(Concurrency with pthreads) -- specifically, the mutex/locking
discipline it covers would need to be applied to file access here
(e.g. via a file lock such as flock(), coordinating access across
separate PROCESSES rather than threads within one process, but the
same underlying "protect the critical section so only one writer
proceeds at a time" principle from that chapter).

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the failure as structurally the same race
condition c3-3 already demonstrated (unsynchronized read-modify-write),
walks through a concrete sequence showing exactly how one instance's
save can silently erase another's change, and names the specific
chapter (c3-3) and the general principle (coordinated locking around
the critical section) that would need to be applied, even though the
chapter's own pthread-based mutex doesn't directly apply across
separate processes without adaptation.