[Looking for Charlie's main web site?]

Understanding the "cost" of cflock, part 1

In a post today on his blog, Ben Nadel did an experiment "Looking At The Performance Overhead Of A Read-Only Lock". (He happened to do it in Lucee, but the concept applies equally to CF.)

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:

[....Continue Reading....]

Comments
Charlie, really well said, and I appreciate the clarity of perspective. Locking -- much like Try/Catch -- was always a kind of "danger zone" topic, it seemed, when I was getting into programming. It was one of those things that was always described TO me as being slow, and perhaps a "necessarily evil". But, since I didn't really understand how locks worked when I was younger, or when I should use them, all this really did was leave me with a general sense of anxiety that using a Lock (or a Try/Catch block) was fraught with peril - abstract, hard to define peril.

It would also be great if the ColdFusion documentation could add more detail to what actually is supported in a "synchronized" Struct or Array. For example, the docs state that Structs and Arrays are always synchronized by default. But, I can recreate "concurrent modification exceptions" and "undefined values" by trying to mutate a struct/array that is currently being iterated-over by another thread. To be clear, I think those errors are _valid_ - but, without documentation that is more specific about which actions are / are not "thread safe", it leaves it as an exercise for the developer to run tests like this.
Thanks for the kind regards, Ben. You're always so helpful in sharing your trepidations, which makes it easy for so many to relate to whatever challenges you may discuss. Then there's also just all the awesome info--and wonderfully formatted code!--that you always offer. You rock!

So about the matter of synchronized arrays, it's worth pointing out first that this IS something new (whether arrays may NOT be sync'ed), since CF2016. And it's indeed documented in at least the CFML Reference for arraynew (more below). Before I share it, note that there's no equivalent indication of any such option to control whether structs are implicitly sync'ed or not.

Back to arrays, of course many will not bother with an arraynew, when they can just use the [] nomenclature to create them implicitly. But what that does in creating an array is at least the default behavior of arraynew, so the below is worth noting. :-)

And to save folks going to dig through the docs page there (or for those who may not bother), I'll quote the main points below.

Note that the doc page clarifies how a new OPTIONAL argument was added, that allowed one to make such an array NOT synchronized/NOT thread safe--if they knew what they were doing. We can liken it to how folks using SQL may, for instance, use NOLOCK directives (but let's not go any further here on that!)

Here's the link to the arraynew docs, and the quote of that discussion there about this "isSynchronized" argument:

https://helpx.adobe....

--
"When false, creates an unsynchronized array. This parameter is new in the 2016 release of ColdFusion. When this parameter is true or no parameter is specified, the function returns a synchronized array.

The default value is true.

In ColdFusion 11, and previous versions, arrays were always thread-safe.

But thread safety comes at a cost of synchronizing the array object. In a synchronized array, two or more threads cannot access the array at the same time. The second thread has to wait until the first thread completes its job, resulting in significant performance deterioration.

In ColdFusion (2016 release), you can use an unsynchronized array and let multiple threads access the same array object simultaneously.

You can use unsynchronized arrays in situations where you need not worry about multiple threads accessing the same array. In other words, if you are defining an unsynchronized array in a thread safe object, like a UDF or a CF-Closure, you can use an unsynchronized array.

While a normal array is slower but thread safe, an unsynchronized array is faster by more than 90%."
--

Before leaving this comment, and for any who have read this far, note again that in my post I acknowledge that some will ask still other questions about when/why/when not to bother with locking. I'll address that more in part 2.
I don't think I've ever tried to make a non-synchronized Struct/Array, so I have no sense of when or if it changed for Structs. The Lucee docs do make some note about synchronized structs:

> Note, the type "synchronized" is no longer supported and will be ignored; all struct/scopes are "thread safe" since version 4.1.

I don't know if that was a brief, Lucee-specific feature that they rolled-back; or, if that was something they had for some ACF compatibility. But, in either case, Structs are always synced at this point.

But, even so, if you throw enough volume at a Struct, attempting to add/remove keys while also iterating over it, eventually you get a concurrent modification errors (at least in Lucee).

Looking forward to part 2 :D
Looking forward to part 2 too!
# Posted By Ariel | 1/23/23 5:14 PM
I hear you, Ariel. I will admit I lost track of this, especially since no one else had mentioned it since June. :-) Thanks for the toggle. Lots going on this week, so I can't promise it won't fall to the back burner again, but I appreciate the reminders/expressions of interest.
Charlie, thanks so much for your reply and for your valuable time. I'm working on a project that uses cflock a lot and maybe I can add some useful information, thanks again!
# Posted By Ariel | 1/24/23 8:24 AM
Ariel, if you may mean you're considering doing a blog post of you're own, that's great to hear. Any contributions to the cf community tend to help broaden understanding.

I have LOTS I could share, and time will tell what I may. I could certainly modify what I'd say by pointing to something you may write, if it may allow me to then focus on still other facets. :-)
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting