[thelist] cflock reads?

Chris Evans chris at fuseware.com
Tue Jan 22 09:22:46 CST 2002


If a read is in progress and not locked, the write will lock the variable
from *new* accesses ( not current reads), then proceed to write.  At that
point, you have a simultaneous read and write and possibly corrupted memory.

Simultaneous reads don't need to be locked if you never write to it.  But
why have a variable that is never written?

There are several cases where you logically don't *need* to lock these
shared variables.  However, as a good coding practice, it makes sense to
always appropriately lock shared variables.  Code can change, developers can
modify other developers code, applications can expand, and so forth. You'd
hate to find out nine months after writing an app that the cause of the
random crashes under high loads is because you never locked a shared
variable (I speak from experience).

But I agree from a logical standpoint - there should never be a point where
session variables have a simultaneous read and write.

Also remember, when checking to see if a shared variable is defined, that
counts as a read and needs to be appropriately locked.

Hope that helps,

Chris Evans
chris at fuseware.com
http://www.fuseware.com






More information about the thelist mailing list