Alot of people are making this incorrect assumption.
Let me give an analogy that should make it easier to remember:
Cold Fusion's Advisory Locking, or "Shotguns in a dark room"
-------------------------------------------------------------------------------
Imagine a big dark room. It is so dark that you cannot see anything in it at all.
Your resource, an important bit of information, is in the room.
When you want to read the information, you hand a "Do Not Disturb" sign on the door
handle and go in to feel around and get a copy of the information. It did not take
you very long to hang up the "Do Not Disturb" sign so your read was not delayed very
much by "read locking".
When you want to write the information you load the information up into your trusty
shotgun (along with a few rounds of buckshot), open the door to the dark room and
start blasting away. However, if there is a "Do Not Disturb" sign on the door OF
COURSE you cannot start shooting because there is someone in the room. You, as writer,
will have to wait until the "Do Not Disturb" sign is taken off the door. If there are
multiple "Do Not Disturb" signs on the door you will have to wait until everyone comes
out of the room and takes their "Do Not Disturb" signs. Your write is potentially
delayed by "write locking" or "exclusive locking".
Now imaging someone wants to read the information. They just need to get it really
quickly and don't bother to hang a "Do Not Disturb" sign because they are only reading
the information and will be really quick anyway.
Chances are no one will come by with a shotgun, and if they do they will take a while
to load it up. But if you take this chance sooner or later someone's gonna get shot!
At 02:30 PM 10/18/00 -0400, Dave Watts wrote:
>> I may be wrong, but my understanding is that reads do not need a
>> lock, only writes.
>
>This is wrong. The point of locking, whether in CF or anywhere else, is to
>control concurrent access to a shared resource. If you were to only lock
>writes, then when someone executed an unlocked read during the locked write,
>they'd access that resource while it's in a transitive state.
>
>This is a common misunderstanding with locks. A lock doesn't really keep
>other requests out, but rather specifies the conditions under which the
>current request will operate. If other requests don't respect that (by
>having their own locks), there's no point in locking.
>
>Dave Watts, CTO, Fig Leaf Software
>http://www.figleaf.com/
>voice: (202) 797-5496
>fax: (202) 797-5444
>------------------------------------------------------------------------------------------------
>Archives: http://www.mail-archive.com/[email protected]/
>Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
>with 'unsubscribe' in the body to [EMAIL PROTECTED]
---------------------------------------------------------------------------
Peter Theobald, Chief Technology Officer
LiquidStreaming http://www.liquidstreaming.com
[EMAIL PROTECTED]
Phone 1.212.545.1232 x204 Fax 1.212.545.0938
------------------------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
with 'unsubscribe' in the body to [EMAIL PROTECTED]
