Ray,
I'm interpreting your statment that if indeed a race condition occurs and
that a variable is overwritten at the same time as its being written, that
it simply uses the second value??  I havent seen anyting to suggest this
anywhere(do you have more info?).  


The problem would seem to me to be more severe as indeed macromedia has made
the statment that you should avoid this by spending time to lock the
variable.  


Assuming the worst case (because of lack of evidence to the contrary), the
variable gets corrupted by this action.  I would think that the server might
be negatively affected by such an occurence and indeed might crash.  Cf5
would crash when its variables became corrupted.  So, perhaps it might be
somewhat important?  Of course I'm fairly java clueless so I cant make a
better guess.


DRE

-----Original Message-----
From: Raymond Camden [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 28, 2003 8:28 AM
To: CF-Talk
Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)

> In addition, you might have variables which just aren't that
> important. For example, in the official Macromedia
> courseware, race conditions are discussed and an example is
> provided. That example uses a variable to store the number of
> users who have logged into the application. But in real life,
> do you really care so much whether a user thinks he's the
> 53rd user or the 54th?

I'd just like to +1 this and add another example. Imagine you want to
know when an application started up. You could do:

<cfif not isDefined("application.startuptime")>
<cfset application.startuptime = now()>
</cfif>

Technically, you should lock this, but honestly, do you really care if N
threads access this code at the same time, and your startuptime ends up
being 5-10 miliseconds off?

  _____  


[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to