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"?
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:
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.
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:
They all can read what is on it, together => Multiple shared locks can co-exist.
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.
-
1very good explanation. However the PO asked bout the origin of "shared" and "exclusive" denominations, not to an explanation of therms per se. – serhio Apr 15 '14 at 9:56
-
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. – Kanagavelu Sugumar Jun 22 '16 at 8:21
-
@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. – ArjunShankar Jun 22 '16 at 12:20 -
1You 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
writeris 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. – ArjunShankar Jun 22 '16 at 12:31 -
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? – Kanagavelu Sugumar Jun 22 '16 at 12:31
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 by another process of a write lock. 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).
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
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.
