What operations on atomicState are atomic?

The docs say that “atomicState.counter = atomicState.counter + 1” should work. If this is right that means it is executing a read and write atomically. In another forum post the response seemed to be the sequential reads could have asynchronous modifications by between them. So I’m guessing something like:

def saved = atomicState.counter
saved = saved + 1
atomicState.counter = saved

would not work right.

So how is it deciding when to execute some statements atomically? If all the access is in the same statement will that work? What about multiple fields, will atomicState.a = atomicState.a + atomicState.b work?


Good question, and I hope ST can give you a definitive answer.

I assume that your first guess is correct: A single “expression” is executed Atomically.

But the details may depend on the knowing the exact sequence of locking and/or use of semaphores in the platform.

I’ve been playing around with this a little more, here’s what is confusing. Here’w what I wrote:

def checkState() {
    if (++atomicState.running > 1) {
    try {
    catch (e) {
        throw e

If what I guessed is correct then this will act as a critical section. It would also allow you to make all sorts of other threading primitives likes locks. If it does work it probably has horrible performance, but who cares. It would seem a little too good to be true though.

1 Like

Fyi… Per reference docs


Though state can be treated as a map in most regards, certain convenience operations that you may be accustomed to in maps will not work with state. For example, state.count++ will not increment the count - use the longer form of state.count = state.count + 1.

Thank you didn’t see that. I’ve only been messing with ST and Groovy for a few weeks.

It can be rewritten to do the same thing using the right operations.

atomicState.running = atomicState.running + 1
if (atomicState.running > 1) {
// etc...
1 Like