> -----Original Message-----
> From: Ben Forta [mailto:ben@;forta.com]
> Sent: Friday, November 01, 2002 12:57 PM
> To: CF-Talk
> Subject: RE: Understanding Locking In CFMX
> Which simply means that any time there can be concurrent access to data
> from different threads there is a risk for a race condition. The
> simplest example? If you have a dozen variables in a shared scope and
> some other process were to read those during an update then there is a
> risk that the thread reading the data may have 6 variables with old
> values and 6 with new values. That should not trash your server, but it
> may mess with your application - that is your choice.

I guess that is my point -- if there is no concrete answer on when to lock,
I'd lock all the time so I don't have to worry about it.

> Any application or development language that allows multiple threads to
> access shared data has to deal with it - operating systems do, as do
> DBMSs, as do development languages. It is not a CF issue at all.

I am aware of that, it just seems like the "when and where" issue of locking
is even more sketchy with CFMX than it was beforehand.

> What was a CF issue was possible memory corruption pre-CFMX. That's been
> fixed. Race conditions? That's for you to determine if they pose a
> problem for your particular application.

The problem that I have with looking at an app and trying to figure out if I
am going to need to lock is, I might as well lock because if I ever have to
add or modify the application, I'll be wasting time going back and locking
other code because new code I've written might cause a race condition with
the prior code.


Thanks for the additional insight!

Andy


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm

Reply via email to