You are correct - if there are two writes then even if you lock one will happen after the other and one will then overwrite the other.
The purpose of locking then is for you to control that so that it is not "random". In other words, if there is a read going on at the same time, do you care if that read gets the old or new value, or not. If not, then under CFMX it'll not be a problem. Locking allows you to control the sequence in which events occur. Of course, some things still should be locked - for example, writing to a file with <CFFILE> (if the file could be access by other threads too). --- Ben -----Original Message----- From: Tyler Silcox [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 7:15 PM To: CF-Talk Subject: Re: CF Wishlist I believe race conditions are where you are setting a variable multiple times per request or session, and your code relies on the changing value to execute properly. For example if you had: <cfset session.MyCurrentStep=1> <!--- then run some other code here then you increase the value of the variable (in this page or another) ---> <cfset session.MyCurrentStep=session.MyCurrentStep + 1> <!--- then you might have a cfif or cfswitch running off the session.MyCurrentStep ---> <cfswitch... You should put a lock around the incrementing section because your code relies on whatever the value of session.MyCurrentStep currently is. If you do not use a cflock, there's always the possibilty that the variable could be set multiple times and end being set to Step 3 if you really should only be on Step 2. I think this can only happen if you start to set the value of the variable and the value is changed before you reach the right side of the equation and it spits out an incorrect value. (hmmm?) Now, why and how this is a problem, I don't know. If the code is going to be run twice (when it isn't supposed to) then you are going to end up with a wrong value for one,or both, of your pages anyways. So I still haven't figured out where the hangups are with the tag itself, by this reasoning, shouldn't we just lock the whole request? Can anyone with a big brain figure this out for us? I've already went though this once on the Beta forums, and everytime I think I have cflock licked, I start thinking about it more and more and it starts making less and less sense. Tyler Silcox email | [EMAIL PROTECTED] ----- Original Message ----- From: "Paul Giesenhagen" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Wednesday, May 01, 2002 5:22 PM Subject: Re: CF Wishlist What is "race" conditions? Paul Giesenhagen QuillDesign http://www.quilldesign.com SiteDirector Commerce Builder > You need to lock to prevent race conditions. If that is why you were > locking then yes, you should. > > But you do not need to lock to prevent memory corruption. So, if that > was the only reason you were locking, then no need. > > > > -----Original Message----- > From: Raymond Camden [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 01, 2002 5:02 PM > To: CF-Talk > Subject: RE: CF Wishlist > > > > > > > From: "Raymond Camden" <[EMAIL PROTECTED]> > > > > > > cflock is _not_ necessary for memory issues anymore. You > > still need it > > > for logical reasons. For example: > > > > > > application.x = application.x + 1 > > > > Whoah - not been following this thread closely, but did I miss > > something? You don't need to habitually lock Session, Server and > > Application variables anymore in CFMX? > > > > Correct. But, it doesn't hurt either. I'll probably continue using it > just to be safe. > > ====================================================================== > = > Raymond Camden, Principal Spectra Compliance Engineer for Macromedia > > Email : [EMAIL PROTECTED] > Yahoo IM : morpheus > > "My ally is the Force, and a powerful ally it is." - Yoda > > > ______________________________________________________________________ Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
