Sean,
This is excellent. I'm going to post your very good example on my blog. I
often see code where the lock is implimented on the set or update rather
than around the condition statement (the <cfif Isdefined('server.myvar')> in
your case).
-mk
-----Original Message-----
From: Sean A Corfield [mailto:sean@;corfield.org]
Sent: Friday, November 01, 2002 12:10 PM
To: CF-Talk
Subject: Re: Understanding Locking In CFMX
On Friday, Nov 1, 2002, at 08:24 US/Pacific, Andrew Tyrone wrote:
> Explains why not locking shared scopes won't crash the server, but
> could
> cause a "race condition" and corrupt data. What I don't get is why
> OTHER
> languages don't need locks around shared scopes, if CFMX is indeed
> thread-safe like they are (ASP to name one).
Other languages DO need locks to avoid race conditions - CFMX is now
par with them. In Java, you need to use the keyword "synchronized" to
apply locking around operations. Some language provide explicit
functions for locking resources, some languages force you to rely on
external semaphores for resource protection.
> To me, that says "You still have to lock everything
> you always had to, unless you want corrupt data."
No, it says you have to think about whether you need to lock or not,
just like in other languages. Consider this construct:
<cfif isDefined("server.myVar")>
<cfset server.myVar = createObject("component","foo")/>
<cfset server.init()/>
</cfif>
If this can be executed by multiple requests simultaneously, you need
to lock it. Where do you need the lock? Just around the update? No, in
this case you need the lock around the whole <cfif.../> tag. Why?
Consider this (bogus) code:
<cfif isDefined("server.myVar")>
<cflock name="server_myVar" type="exclusive">
<cfset server.myVar = createObject("component","foo")/>
<cfset server.myVar.init()/>
</cflock>
</cfif>
Two requests begin to execute this, they both execute the test and find
server.myVar is not defined so they both try to lock - one of them gets
the lock and initializes it all. Then the other request is given the
lock and it initializes server.myVar again.
The following is the safe way to do this:
<cflock name="server_myVar" type="exclusive">
<cfif isDefined("server.myVar")>
<cfset server.myVar = createObject("component","foo")/>
<cfset server.myVar.init()/>
</cfif>
</cflock>
Now let's think about multiple requests accessing server.myVar - if
they are just retrieving the value, there won't be a problem. What
about an update? If one request sets server.myVar to some new value,
what could happen? It's an atomic value so requests won't corrupt it.
In other words, you can manipulate the single variable server.myVar
without locking (unless you care about its previous value as in the
initialization above). Up to a point (dependent on the specifics of
your application).
Now think about calling methods on server.myVar - if you call methods
that don't change the state of the object, are you safe? It depends.
Suppose you two data members inside the object, firstName and lastName.
Suppose you have a method, getFullName(), that returns firstName & " "
& lastName. Suppose you also have a method, setName(), which takes two
arguments for a new first name and a new last name. These operations
are NOT atomic so both the update AND the read will need locking
(exclusive for the setName() calls, readonly for the getFullName()
calls).
> If I am wrong about this, can anyone explain in English, so my tiny
> little
> brain can comprehend why?
Locking is a hard subject to deal with. Changing policy from 'lock
everything' to 'lock only when you need to' is a big jump. The simplest
way to think about it now is 'if in doubt, lock it!' but the long-term
goal should be to develop an understanding of how multi-threaded handle
resource contention. No one should expect to 'get it' immediately - we
should expect to see lots of questions on this topic!
"SOAP is not so much a means of transmitting data
but a mechanism for calling COM objects over the Web."
-- not Microsoft (surprisingly!)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
This list and all House of Fusion resources hosted by CFHosting.com. The place for
dependable ColdFusion Hosting.
