In recent years, that is
in past 5 years Linux has seen significant growth as a server operating system
and has been successfully deployed as an enterprise for Web, file and print servicing.
With the advent of Kernel Version 2.4, Linux has seen a tremendous boost in scalability
and robustness which further makes it feasible to deploy even more demanding enterprise
applications such as high end database, business intelligence software ,application
servers, etc. As a result, whole enterprise business suites and middleware such
as SAP, Websphere, Oracle, etc., are now available on Linux. For
these enterprise applications to run efficiently on Linux, or on any other operating
system, the OS must provide the proper abstractions and services. Usually these
enterprise applications and applications suites or software are increasingly built
as multi process / multithreaded applications. These application suites are often
a collection of multiple independent subsystems. Despite functional variations
between these applications often they require to communicate with each other and
also sometimes they need to share a common state. Examples of this are database
systems, which typically maintain shared I/O buffers in user space.Access
to such shared state must be properly synchronized.
Allowing multiple processes
to access the same resources in a time sliced manner or potentially consecutively
in the case of multiprocessor systems can cause many problems. This is due to
the need to maintain data consistency, maintain true temporal dependencies and
to ensure that each thread will properly release the resource as required when
it has completed its action. Synchronization can be established through locks.
There are mainly two types of locks: - Exclusive locks and shared locks. Exclusive
locks are those which allows only a single user to access the protected entity,
while shared locks are those which implements the multiple reader - single writer
FUTEX_WAIT : This operation atomically verifies that the futex address still contains the value given, and sleeps awaiting FUTEX _ WAKE on this futex address. If the timeout argument is non-NULL, its contents describe the maximum duration of the wait, which is infinite otherwise. It is similar to the previous FUTEX_ DOWN , except that the looping and manipulation of the counter is left to userspace
FUTEX_WAKE : This is similar to the previous FUTEX_UP , except that it does not alter the futex value, it simple wakes one (or more) processes. The number of processes to wake is controlled by the " int val " parameter, and the return value for the system call is the number of processes actually woken and removed from the hash table. It returns the number of processes woken up.
FUTEX_AWAIT : This is proposed as an asynchronous operation to notify the process via a SIGIO-style mechanism when the value changes. The exact method has not yet been settled (see future work in Section 5). This new primitive is only slightly slower than the previous one, 6 in that the time between waking the process and that process attempting to claim the lock has increased