Most people believe that Since JavaScript does not provide a multi-threaded shared memory environment, JavaScript is completely free from concurrency issues. This is true at a low level; JavaScript developers don't need to worry about race conditions between multiple processes or threads writing to the same memory location. At a higher level, asynchronous operations still allow for similar problems to occur.

Imagine a function that does the following:

1. Check the value of a variable.
2. If the value is undefined:
   1. Make a request to a server.
   2. Receive data.
   3. Set the value of the variable.
3. Pass the variable to a callback function.

It seems common for web applications to lazy load data like this as needed. Now imagine that there are several separate modules within a web application which all require this data. It's possible for the first module to call this function, the function sees that the value is undefined, and sends a request to a server. Then before the request returns, the second module calls this function, the function sees that the value is undefined and sends a request to a server. Then before both of those requests return, the third module calls this function, the function sees that the value is undefined and sends a request to a server. In this case, three requests are made to a server for the same data.

It would be far better if the second and third calls to the function just waited for the first request to complete. Y.Mutex makes it easier to accomplish this functionality.

Y.Mutex provides a concept of locking a resource. Once an exclusive resource lock is obtained, other parts of an application which attempt to access the same resource, will have to wait until that resource is unlocked.

The function above could be rewritten as follows:

1. Obtain an exclusive lock for a variable.
2. Check the value of the variable.
3. If the value is undefined:
   1. Make a request to a server.
   2. Receive data.
   3. Set the value of the variable.
4. Unlock the variable.
5. Pass the variable to a callback function.

This way, second or third or more calls to the function, before the first request is complete, will always wait for the request to complete instead of sending multiple unnecessary requests.

Just like locking in multi threaded applications, there are disadvantages and dangers to locking. There is a small amount of overhead added to every resource access, even when the chances for concurrency issues are very small. Once a lock is obtained, it must be unlocked; so error handling and time outs are important to ensure that the entire application doesn't break when something goes wrong. It is possible to cause a deadlock when locking multiple resources at once.

One advantage Y.Mutex has in JavaScript over other multi threaded applications, the locks are asynchronous. The application is not blocked while waiting to acquire a lock. Even if a deadlock occurs, other parts of the application are not affected. Y.Mutex also provides multiple ways to cancel a particular lock, so there are extra possibilities to recover from locking errors.

Y.Mutex offers exclusive locks, shared locks, and upgradable locks. When a resource is locked by an exclusive lock, Y.Mutex guarantees that no other locks will be granted for the resource until the resource is unlocked. When a resource is locked by a shared lock, Y.Mutex allows the resource to be locked by an unlimited number of other shared locks at the same time and/or one single upgradable lock. When a resource is locked by multiple shared locks, an exclusive lock can not be obtained until all of the shared locks have been unlocked. An upgradable lock can be upgraded to act as an exclusive lock. Shared locks are generally used when just reading values. Exclusive locks are generally used when writing values.

Y.Mutex provides a way to deal with asynchronous concurrency issues, but it does not prevent them. If code from part of an application uses Y.Mutex to lock a resource, there is nothing stopping code from another part of the application from ignoring the lock and accessing the resource directly. Y.Mutex does not handle real multi threaded or multi process concurrency issues.