reg_or_update_shared_local_counter

[edgurgel]

I may be asking something stupid, but I need to know :)

I think I'm getting some race conditions using a shared local counter. Is there any way to register OR update a shared local counter? I imagine that's possible as the shared counter is unique and it must be linked to gproc itself, right?

If it's not possible, how could I work this out or may be add it to gproc? Any thoughts?

[edgurgel]

Thinking again, I see that my issue maybe solve having a reg_or_locate for shared counters. Is that possible?

[uwiger]

How about this:

safe_incr(C, Incr) ->
    K = {c,l,C},
    try gproc:update_shared_counter(K, Incr)
    catch error:_ ->
             try gproc:reg_shared(K, Incr), Incr
             catch error:_ ->
                      gproc:update_shared_counter(K, Incr)
             end
    end.

[uwiger]

A reg_or_locate_shared() feels a little bit weird when I try to get a feeling for the semantics. Possibly an ensure_shared_reg(Key, Value)?

[edgurgel]

The safe_incr can still fail, right? It would need an infinite try catch as the reg/unreg can happen between the try catch treatment. Or am I understanding something wrong?

The reg_or_locate_shared name would be based on existing functions reg_shared and reg_or_locate, but I agree that it's not really meaningful alone.

What about reg_or_locate support the shared atom as other functions do? And the ensure_shared_reg/2 would be an alias?

Do you think that's a good enhancement to gproc?

I advocate for this inclusion as it would be possible to keep shared counters without the trouble of building a safe critical session when creating/destroying shared counters.

[edgurgel]

And now thinking about the counter, it would be a better approach to reg_or_locate and update the counter if exists.

update_or_reg_shared_counter ?

[uwiger]

I think the three catch levels should be enough:

1. Either the increment succeeds, or the counter isn't there
2. Either we succeed in creating the counter, or someone beat us to it
3. If 2 fails the counter should still be there; then we increment.

The last increment should not have a catch, since it should fail for most other cases.

I'm sure one can create a bizarre case where another process first creates, then deletes the counter...

I'll think about what a new API function should look like.

Ulf Wiger
http://ulf.wiger.net/

25 jul 2013 kl. 23:06 skrev Eduardo Gurgel notifications@github.com:

The safe_incr can still fail, right? It would need an infinite try catch as the reg/unreg can happen between the try catch treatment. Or am I understanding something wrong?

[edgurgel]

Ok, thank you Ulf. I will just explain my use case:

I have processes based on an associated id that when they spawn, they:

• Check if a shared counter with their id already exists
• If it exists increment
• Otherwise create one

If another process with the same associated id spawn, they do the same.

When they terminate, they decrement. If it reaches zero, destroy the shared counter.

The creation/destruction can happen during the steps described above.

Resuming it would be awesome to have:

• reg_or_update_shared_local_counter(...., InitialValue, UnregValue)

Where if the counter reaches the unregvalue, for example 0, -1, it becomes unregistered.

Maybe this is too crazy. Thank you again! 👍

[uwiger]

Considering the fact that many already think that the gproc API is bloated, I think I'll pass on adding this function. ;-)

[edgurgel]

I agree @uwiger and I think this change (erlang/otp#362) will solve my problems (considering that gproc will use it also if it gets merged).

[uwiger]

Indeed.