Published on Jun 05, 2023
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 semantics.
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.
