@jhogberg, I don't mind submitting a patch for this myself if that means it will be included in the OTP 28 release.

I'm afraid it's too late for OTP 28. I'm experimenting with a refactor of persistent_term for 29 however, and will see about adding this while I'm at it. :-)

@Benjamin-Philip I don't think this is needed. You don't need to serialize every access to the persisted terms through a gen_server. Only reads that find that the key does not exists and that want the key to be created, need to be serialized. That would apply to only a few of the first reads.

Even if multiple readers find that key does not exits, they would call the gen_server, which would check again that the key exists and create it if not. That way only the first call to the gen_server would create the key, the others would simply return the now existing value.

This should work nicely:

get_term(Key) ->
    case persistent_term:get(Key, undefined) of
        undefined ->
            gen_server:call(?SERVER, {get_term, Key});
        Value ->
            Value
    end.

...

handle_call({get_term, Key}, From, State) ->
    Ref = case persistent_term:get(Key, undefined) of
              undefined ->
                  R = atomics:new(?Arity, ?Opts),
                  ok = persistent_term:put(Key, R),
                  R;
              Value ->
                  Value
          end,
    {reply, Ref, State};

@RoadRunnr, that is what I am effectively doing now.

I'm afraid it's too late for OTP 28. I'm experimenting with a refactor of persistent_term for 29 however, and will see about adding this while I'm at it. :-)

I see. I worked on a patch during the weekend and it's almost PR ready... Could it be merged to master even if it isn't included in the OTP 28 release? Or would you prefer that I discard it and leave implementing this to you after the refactor?

Could it be merged to master even if it isn't included in the OTP 28 release?

No, anything merged to master before the release will be included in 28.

Or would you prefer that I discard it and leave implementing this to you after the refactor?

The refactor is almost done but I haven't decided on including it yet, there are some trade-offs with my new approach that I need to square first. If yours is almost ready, feel free to open a draft PR with your code in whichever state it is, and we'll revisit it if I decide not to refactor. :-)