What's the difference between an exclusive lock and a shared lock?

Question

According to wikipedia:

Shared locks are sometimes called "read locks" and exclusive locks are sometimes called "write locks".

Can you explain the reasoning behind the terms "shared" and "exclusive"?

Flavory

Is non-exclusive lock is another name of shared lock? – Nitrification

Answer 1

I wrote this answer down because I thought this would be a fun (and fitting) analogy:

Think of a lockable object as a blackboard (lockable) in a class room containing a teacher (writer) and many students (readers).

While a teacher is writing something (exclusive lock) on the board:

1. Nobody can read it, because it's still being written, and she's blocking your view => If an object is exclusively locked, shared locks cannot be obtained.

2. Other teachers won't come up and start writing either, or the board becomes unreadable, and confuses students => If an object is exclusively locked, other exclusive locks cannot be obtained.

When the students are reading (shared locks) what is on the board:

1. They all can read what is on it, together => Multiple shared locks can co-exist.

2. The teacher waits for them to finish reading before she clears the board to write more => If one or more shared locks already exist, exclusive locks cannot be obtained.

Geanine

very good explanation. However the PO asked bout the origin of "shared" and "exclusive" denominations, not to an explanation of therms per se. – Trant

Is this "If one or more shared locks already exist, exclusive locks cannot be obtained." is true? interms of ReentrantReadWriteLock? I thought Write lock can be obtained at any time, otherwise starvation for write may happen due to continuous reading. – Skiing

@KanagaveluSugumar, yes, it's true. You simply cannot obtain a write lock when another entity already holds a read lock on the same object. That's the whole point of a read-write lock. If you happen to overwrite something while someone else is reading it, what then would they read? I don't know why you chose to pick out a "re-entrant" read-write lock specifically, but re-entrancy means that the owner of a re-entrant lock can 'lock()' it again and all subsequent lock() calls after the first one will return immediately and successfully. i.e. you can successfully lock something you already own. – Geanine

You also mention that "I thought Write lock can be obtained at any time, otherwise starvation for write may happen due to continuous reading" - this simply cannot be. A write lock cannot be obtained while some other entity already holds a read/write lock. What can happen is that if multiple entities are already waiting to lock an object, then a waiting writer is given preference over waiting readers when the lock chooses who gets the lock next (when it is unlocked by its current owner). This is about policy. – Geanine

Thank you! I have chosen ReentrantReadWriteLock; since that is the implementation class for ReadWriteLock in java. Then Is there any flag raised or more priority set to say further new read threads to wait when write thread is started waiting? Because how to avoid starvation of write thread because of continuous read request? – Skiing

@KanagaveluSugumar, I don't know much about Java and the Java class library, but it appears that this question and its answer deal with your issue. However, apparently, according to the answer there, this option isn't there in ReentrantReadWriteLock. – Geanine

I want to clarify once more, on a statememt you made. You want that "further new read threads to wait when write thread is started writing". This is the default and only sane behaviour of read-write lock. If a write lock is already held, then new threads requesting either read or write locks will not get it. Their calls to lock() will block. – Geanine

If you are referring to a starvation that occurs when multiple readers keep requesting a read lock and a waiting writer never gets to perform a write, that's about the policy used by the lock to decide which is the next thread to receive the lock. It's not about locking itself. Locking itself always works the same way: if a writer holds a lock, other readers and writers will have to wait for it to finish and release the lock before they can continue. – Geanine

I am not sure if I misunderstood what you wrote or if you used the wrong words to describe the behaviour you want, but I hope this clears things up. Cheers! – Geanine

@Geanine perfect answer. But if there is a process "select * from table blackboard" executing (not finish) and an insert operator happens what will happen? Does the insert operator wait for the select operator or doesn't? Do select * apply share lock to "new record"? – Plexus

Answer 2

It's pretty straightforward. Read locks are also known as shared locks because more than one process can read at the same time. The point of a read lock is to prevent the acquisition of a write lock by another process. By contrast, a write lock inhibits all other operations while a write operation completes which is why it is described as exclusive.

So a read lock says "you can read now but if you want to write you'll have to wait" whereas a write lock says "you'll have to wait".

---

I realise you're researching in support of your studies, but I can't resist the urge to lecture.

Incompetent use of locking is a primary cause of performance headaches. Use of a locking system that differentiates read and write locks is a good start, but careful design can sometimes eliminate much of the need to lock. For example, session state should never be held in one global collection per element of state.

I have actually seen this done. It's an atrocious design, causing boxing and a change to a collection for every last change to session state, entailing a protracted write lock. Overheads were crippling, effectively reducing the server to single threaded behaviour.

Simply aggregating all the session state into a struct was a huge improvement. Changes to session state merely changed the values of members of a session's state struct. Since no other session had occasion or even opportunity to directly reference a session's state, the only collection being updated was the list of sessions. As a result, locking was completely unnecessary during a sesssion, only at the start and end, and throughput rose by a factor of 3000.

The other common locking scenario is resources shared between threads of a user application. Most modern frameworks address this using messages rather than locks; when you "transition to the UI thread" you are actually queueing a message containing a function pointer and some parameters (or a delegate and a stack frame depending on implementation).

Jemmy

"Most modern frameworks address this using messages rather than locks" There is some official name for this message technique? I searched for it and I didn't found any issue about it – Commando

Answer 3

• An exclusive or write lock gives a process exclusive access for writing to the specified part of the file. While a write lock is in place, no other process can lock that part of the file.

• A shared or read lock prohibits any other process from requesting a write lock on the specified part of the file. However, other processes can request read locks.

More on that : http://www.gnu.org/software/libc/manual/html_node/File-Locks.html

Oversubtlety

Answer 4

Principle same on the database side as well. As per the Oracle documentation

Exclusive lock mode prevents the associated resource from being shared. This lock mode is obtained to modify data. The first transaction to lock a resource exclusively is the only transaction that can alter the resource until the exclusive lock is released.

Share lock mode allows the associated resource to be shared, depending on the operations involved. Multiple users reading data can share the data, holding share locks to prevent concurrent access by a writer (who needs an exclusive lock). Several transactions can
acquire share locks on the same resource.

Dorris

Answer 5

• Exclusive lock doesn't allow read and write operations.

• Shared lock allows only read operation.

Platinize