Feature: atomic (critical-section sugar)

[fibodevy]

atomic

I have an idea I think is great - I came up with it myself, but then found out other languages have it too, of course... Everything that might be useful is already implemented somewhere: lock / synchronized / std::lock_guard / std::scoped_lock / lock & defer unlock...

FPC Unleashed version: atomic(optional args) <expr>;

Sugar for initCS + enterCS-try-finally-leaveCS-end + doneCS.

atomic inc(i);                 // lock by source location
atomic(i) inc(i);              // lock by "i"
atomic(i, cls) i += cls.value; // lock by multiple vars/objects
atomic begin {...} end;        // <expr> can be begin-end

atomic expands to:

1. Init CS in unit/program initialization
2. Done CS in unit/program finalization
3. atomic: enter CS -> try -> EXPRESSION -> finally -> leave CS

Instead of doing all the initialization and finalization, coming up with a name for the CS, remembering it, entering it, leaving it, and writing the try-finally - you simply call atomic. IMHO brilliant.

Naming

atomic or lock are on the table. Feedback welcome.

---

Thoughts?

[Thaddy]

Well,
AtomicIncrement(i) is in system, why write Atomic inc(i) ?
AtomicIncrement is an alias for InterlockedIncrement for Delphi compatibility.
Also on many systems simple types are already atomic if they have the size of a register or less and don't need a cs.

I would love the feature for complex or larger types though or for operations on simple types that have no InterlockedXXX equivalent.

[fibodevy]

Thanks a lot for jumping in here - it genuinely means a lot to me. (And if you feel like leaving a star, that'd make my day 😄)

To clarify: inc() was just a throwaway example - the point was never to replace AtomicIncrement for simple types. The atomic keyword (or lock, if that reads clearer) is sugar for a critical section, not for lock-free atomics.

The whole win is killing the boilerplate. A traditional CS means: declare it, InitCriticalSection somewhere, DoneCriticalSection somewhere else, then Enter / try / ... / finally / Leave around every use. All of that collapses into one statement:

lock begin
  // ...protected code...
end;

// or keyed to a specific object/var:
lock(myObj) begin
  // ...
end;

[Thaddy]

This is a fine improvement. Go ahead... ;)

[fibodevy]

atomic or lock? Or perhaps something else? Since atomic appeared to cause some confusion, would lock be a better keyword?

[Thaddy]

The compiler generates code with lock prefix for those (1,2,4,8 bytes on X86_64)

lock inc dword ptr [mem]
//or
lock add qword ptr [mem], 1

If a result is necessary the compiler generates:

mov  eax, 1
lock xadd dword ptr [mem], eax  ; eax gets old value
inc  eax                         ; eax becomes new value
// or
mov  rax, 1
lock xadd qword ptr [mem], rax
inc  rax

That code is much, much better than a cs, so beware of that.
I will also check for ARM/AARCH a bit better. It may/will differ per processor, but you have to keep that in mind:
At least for ARM and Intel, the Atomic/Interlocked family already performs optimal and a cs would harm instead of help.

[Thaddy]

But I welcome the atomic keyword if it simply generates the same code as above for simple types 1-4 on 32 and 1-8 on 64. Note that reads are already always atomic for those.
If atomic is only used for those types, the compiler should not create a cs, only on complex types/blocks.
Also note there are cpu core level readbarrier/writebarrier and readwritebarrier in system. These are - I think - also more lightweight and may apply..

[Thaddy]

Forget the barriers. Only useful in some cases and are not really threadsafe.
From a multi-platform point of view, some googling reveals that a cs may indeed be the best option unless you want to take advantage of the processor specifics like a lock prefix in Intel/AMD's.
You have my blessing.

[Cooler2]

I had similar idea too. Would be nice to have something like:
begin(cs) xxx; end;
or
within(cs) do xxx;
which expands to

cs.Enter;
try 
  xxx 
finally
  cs.Leave;
end;

But I'm not sure this is a compiler scope, for me it's more a preprocessor job.