list yet, so I'm sending again.
Thanks Barney, Peter, and Reed for your responses.
After reading Barney's article, I still have one more question.
When you have a race condition on unlocked shared memory variables, what
are the possible negative results? Is it...
A) Corruption/errors involving the CF Server itself, as well as lapses in
the correctness of your application logic
OR
B) ONLY lapses in the correctness of your application logic
For example:
<CFSET APPLICATION.SloppyCounter = APPLICATION.SloppyCounter + 1>
Assume my application logic wants to increment that counter, but doesn't
care if that counter is 100% accurate. So, if every once in a while when a
race condition occurs the counter misses a hit, my application logic
doesn't care. Does that line need to be locked? If CF Server errors can
result from race conditions, then it needs to be locked. If application
logic errors are the only negative result of the race condition, then it
seems that that line doesn't need to be locked since in that case complete
correctness is not required.
Thanks,
Conan
>At 01:43 PM 3/10/2004, you wrote:
>I wrote up a lengthy article about locking in response to this thread. I
>know I'm not Ben Forta, but it's been something I've been meaning to do for
>a while, and this was the impetus that finally made it happen.
>
>http://www.barneyb.com/blog/archives/2004_03.shtml#000069
>
>Cheers,
>barneyb
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
