The definition of a race condition is (if I recall correctly): Inconsistent computation or results that occur when events or execution occurs in an uncontrolled sequence.
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. 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. 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. --- Ben -----Original Message----- From: Andrew Tyrone [mailto:atyrone@;optonline.net] Sent: Friday, November 01, 2002 12:15 PM To: CF-Talk Subject: RE: Understanding Locking In CFMX Ray, What other web scripting languages have to worry about race conditions? As far as I remember, ASP and PHP do not suffer from this problem. So if this type of functionality (not having to lock shared scope variables, which is really anti-functionality) is attainable, how come CFMX was not programmed in this way? After all it IS a new product. Also, you didn't answer the main question: why does the article imply that locking is not required, but then imply you "might" have variable corruption issues? Either you have to lock or not -- how can there be an in-between when developer's need a concrete way to work with these types of variables so they can build robust apps? I'm not trying to be difficult, it just seems like this article says one thing and then totally refutes it at the same time! :) Andy > -----Original Message----- > From: Raymond Camden [mailto:jedimaster@;macromedia.com] > Sent: Friday, November 01, 2002 11:47 AM > To: CF-Talk > Subject: RE: Understanding Locking In CFMX > > > Maybe I'm wrong - but other languages DO have to worry about race > conditions. It's not a question of CF missing some feature but a > matter of fact. Now, in the past, CF could possibly crash just > _reading_ these types of variables - and certainly that was an... > issue (grin), but that is not the case anymore. > > -----Original Message----- > > From: Andrew Tyrone [mailto:atyrone@;optonline.net] > > Sent: Friday, November 01, 2002 11:25 AM > > To: CF-Talk > > Subject: Understanding Locking In CFMX > > > > > > There was another post about this I could've responded to, but I > > deleted it, hence this new post. > > > > This article: > > > http://www.macromedia.com/v1/Handlers/index.cfm?ID=23021&Method=Full > > 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). Basically this > article says > "The good news is your server won't crash -- the bad news is, your data > will > be totally useless." To me, that says "You still have to lock > everything > you always had to, unless you want corrupt data." I'm sorry, but it > seems > like a lot of double-talk to me. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
