[erlang-questions] Cross OTP version compare-and-swap semantic on ETS

[Sverker Eriksson]

On 10/12/2017 01:15 PM, Benoit Chesneau wrote:
> Thanks for the answer :)
>
>> On 12 Oct 2017, at 10:17, Chandru 
>> <chandrashekhar.mullaparthi@REDACTED 
>> <mailto:chandrashekhar.mullaparthi@REDACTED>> wrote:
>>
>> On 12 October 2017 at 09:01, Benoit Chesneau <bchesneau@REDACTED 
>> <mailto:bchesneau@REDACTED>> wrote:
>>
>>     Hi all,
>>
>>     I’m looking on the best way (in term of concurrency and response
>>     speed) to provide a equivalent of compare-and-swap semantic on
>>     differs Erlang version with ETS. 
>>
>>
>>     For now what I do is using `select_replace/2` on OTP 20 and for
>>     other versions I’m using a pen_server to serialise the writes on
>>     this values, making this gen_server a bottle neck. Which is fine
>>     for a small list of keys to update. I didn’t find any other
>>     solution to do it right now. But maybe someone has an idea?
>>
>>
>> The only thing I can think of is to partition the key space and use 
>> multiple ETS tables (with a dedicated process for each).
>
> True. I can do that indeed … That may be the easiest thing to do in 
> the long term.
>
> For now I I did this simple lib: 
> https://gitlab.com/barrel-db/lab/ets_cas with limited test coverage.
>
>>
>>     Also something I’m currently missing is the possibility do the
>>     dame for delete. `select_delete` isn’t atomic right?
>>
>>
>> Not sure what you mean by 'atomic' here. I expect ETS will delete 
>> whatever entries have matched this specified pattern at that point in 
>> time. In the context of ETS operations, the consideration of whether 
>> it is 'atomic' or not makes sense in the 'insert', 'replace' or 
>> 'update' scenario.
>
>
> I’m not sure what’s the difference between a delete and a replace 
> there with the current ETS librarie 20.1 . By atomic I mean atomic at 
> the key level, ie 2 concurrent delete  will be serialisable which 
> seems to be the case for `select_replace` .
>
>

All ets:select* functions are atomic per table object.
That is, each match-and-* operation is atomic. The iteration is not.


/Sverker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171012/b6bcdff5/attachment.htm>