And I wanted to offer some additional thoughts--first planning to offer them as a comment--because there's a lot behind the question and his observations. But as it got longer, I realized it was too long for a comment. Also, I didn't want people to think (in reading a comment on Ben's blog) that I was challenging Ben or questioning his understanding of the matter! Not at all. :-) Instead, I was just wanting to add more context, to help other readers, and based on my years of observing the community.
What I offer here is pretty much exactly what I wrote, but I have added headings, to help readers here:
Interesting thought experiment, Ben. If you'd been taking bets, I'd have put down good money that there'd be virtually NO impact in this scenario. The reason I say that may add some value to this post, whether one is using Lucee or ACF.
I find that many people do think (or fear) that cf locks do things which "may be expensive"--or conversely they give no attention and use them only because they vaguely recall they're "supposed to" in some situations.
What locks DO doTo clarify for some readers, a cflock does not "lock code" nor does it "lock scopes". Like you said, it can "essentially single-threads access to a given block of code". Nicely worded. :-)
A cf lock is a "gentlemen's agreement" (pardon my boomerism): when the cflock is hit, it causes cf to simply check, "is anyone else holding a contending i TYPE of this lock", of this NAME or SCOPE? That's really it.
If my TYPE is "read", and no one else holds an "exclusive" lock of the same name or scope, I can proceed, otherwise I wait. If my type is "exclusive" is and no one else holds a "read" OR "exclusive", I can proceed, otherwise I wait.
How lock timeouts get involvedAnd the "wait" is controlled by the TIMEOUT atrribute (in the tag) or argument (in script). That's why one is required.
Many misconstrue the TIMEOUT as having impact on "how long the thing in the lock can take", but it's not that at all. It's merely how long do I wait for another request (or thread) holding the same/contending lock to let it go.
And if that timeout is exceeded, then I'll throw an error... unless the optional THROWONTIMEOUT is set to "no". Please BEWARE using that. Many do without any idea of the implications. If you ignore the timeout, then the code in your lock will simply NOT BE RUN. Many folks find mysteriously that some variable is not set or some "code has not run", and this is why.
We have so little insight into these goings-on in a CF request/sSadly, cf gives us zero insight into any of this. I've long lamented that we should have at LEAST optional logging of when a lock timeout occurred, or was ignored this way, or simply how long we have WAITED for or HELD a lock.
To me, misuse/misunderstanding of locks is a cancer in much cf code, causing needless holdups or unexpected failures to run code. That's why I felt I should add this.
Some natural next questionsOf course, the next question some would ask would be "well, when should I or should I NOT use locks". And when should I use read or exclusive types? And others may ask, "I thought the SCOPE lock locked the Scope. You're saying it doesn't?" It does not. Finally, when might you use a NAME lock instead?
[Those are all fodder for a part 2 post. :-) And in the interest of time, I do want to get this out, as-is, as a part 1, thus this post. hope this part 1 helps some, while news of a part 2 may whet the whistle of others.]
Bottom lineBut bottom line to Ben's original post, nope, there's no reason a lock ITSELF should "take time". It's just that check to say "does anyone hold a contending lock of the kind I want"? That alone is a trivial matter. Any delay due to the lock will be only if there IS contention FOR that lock.
So again, look for a part 2 to come. I welcome comments, whether here or on Ben's post--preferably only if such a comment there would be written without presuming people HAVE read this post.
For more content like this from Charlie Arehart:
Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed