Skip to content
This repository has been archived by the owner on Mar 22, 2023. It is now read-only.

FEAT: Atomic Put If Absent #242

Open
pbalcer opened this issue Jun 21, 2019 · 3 comments
Open

FEAT: Atomic Put If Absent #242

pbalcer opened this issue Jun 21, 2019 · 3 comments
Labels
enhancement New feature or request

Comments

@pbalcer
Copy link
Member

pbalcer commented Jun 21, 2019

vmemcache_put_if_absent()

If the key is not present in the cache put the key to the cache atomically.

Value existingValue = vmemcache_get(key);
if (existingValue == null) {
      vmemcache_put(key, value);
      return null;
} else {
      return existingValue;
}

But combine the two steps atomically.

From: Xie, Qi [email protected]

@pbalcer pbalcer added the enhancement New feature or request label Jun 21, 2019
@kilobyte
Copy link
Contributor

I don't quite see an use case here: put already throws EEXIST when the key exists, thus there are no overwrites — ie, two puts won't conflict.

As for get-put conflicts: the eviction policy is either none or LRU. With the former, you can do the put first (your proposed interface already requires calculating the value), while with LRU the cache may drop a key at any moment for unobvious reasons, thus atomicity between operations hardly matters.

Am I missing something?

@pbalcer
Copy link
Member Author

pbalcer commented Jun 21, 2019

This is a common pattern in functional programming languages for idempotent inserts, where you have functions like map.get_or_else(), map.entry(xxx).or_insert(yyy). This is a way to avoid an extra lookup and have shorter code.
Now, we already have something like that through our callbacks, but this may be more convenient to use in Java since there's no C->Java callback.

@kilobyte
Copy link
Contributor

on_miss callbacks are not atomic. Here's a scenario:

T1: get(KEY) → on_miss
T2: put(KEY, VAL2)
T1: on_miss → put(KEY, VAL1) → satisfies the get, then fails

So T1's get will receive VAL1 while the cache will have VAL2.

Whether this is a deficiency or not is up to debate, but that's how current code behaves. Any other puts are serialized wrt gets, only on_miss callbacks are affected.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants