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

Benoit Chesneau bchesneau@REDACTED
Thu Oct 12 13:15:30 CEST 2017


Thanks for the answer :)

> On 12 Oct 2017, at 10:17, Chandru <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 <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` .

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


More information about the erlang-questions mailing list