In previous blog posts, I have described how the operating system solves locking problems. Now a days, Linux is popular and it is a good idea to try to solve problems in
user code. This makes application code much easier to port and goes a long way in making it platform independent. So I would now like to describe a Locking Mechanism that is completely implemented in user space. So what features do we want to support:

1) Multiple readers.
If there is no writer, then there can be multiple readers.

2) Zero or one writers.
There can only be 0 or 1 writers at a time.

3) Multiple readers and writers without data corruption.
It should not matter how many users are trying to read and write a particular item.
The results should always be determinate.
That is, there should never be the chance of data corruption when users are
trying to read an item that is simultaniously being written.

4) Wait fairness
If a user is blocked from accessing an item (because it is in use by a competing user),
then there should be some type of queuing mechanism to ensure the first user
to wait is the first to get item access when the blocking is released.
If this mechanism is missing, then users could theoretically wait forever.
In addition, if an item is read locked, then a write request should block
subsequent readers.

5) Ensure lock/unlock sanity.
A reader or writer cannot unlock an item unless it has already locked the item.
This sanity check helps prevent data corruption.
If a user unlocks a lock that it does not own, then the lock owner does not
know that the item is no longer protected.
And subsequent writes could result in data corruption.

6) Speed.
We want to make the locking process as fast as possible.
We thus cannot call malloc().

That is all for this post. In my next post, I will present the prototype for this facility.