Testing For / Default distributed.Variable Value

[jamesstidard]

Hi,

I'm hoping to use distributed.Varaible as a read counter for a Read/Write Lock I'm building from Dasks synchronisation primitives.

Is there a way to test for the existence of a variable before calling distributed.Varaible.get on it? Or without having to call distributed.Varaible.set and overriding a potentially already set value?

At the moment, calling distributed.Varaible.get before a distributed.Varaible.set will block.

If there's not a way to test if the variable already has a set value under a name, would it be possible to add that, or maybe have a option in either get or set for a default value to be returned if none set (akin to dict.setdefault or dict.get(key, default)?

Thanks.

EDIT: returning distributed.Varaible.get returning None or raising a Exception would also be fine.

[fjetter]

I'm hoping to use distributed.Varaible as a read counter for a Read/Write Lock I'm building from Dasks synchronisation primitives.

What additional functionality on top of distributed.Lock or distributed.Semaphore are you looking for?

If there's not a way to test if the variable already has a set value under a name

You should be able to call Variable.get with a timeout to check if it is set.

If you want more specific feedback, it should be relatively easy to implement an is_set method which works similar to the existing get. If this is what you are looking for, would you be willing to open a PR?

[jamesstidard]

Hi fjetter, cheers for the response.

What additional functionality on top of distributed.Lock or distributed.Semaphore are you looking for?

I want the ability to have a lock for file access, where multiple readers are allowed, but any writes must prevent reads/other write (ref). Here's the code I've started to build before I ran into this issue:

from distributed import Lock


class _ReadWriteLock:
    def __init__(self, name, client) -> None:
        self.name = name
        self.write_lock = Lock(name=f"{name}-write", client=client)

    async def __aenter__(self):
        await self.acquire()
        return self

    async def __aexit__(self, *args, **kwargs):
        await self.release()


class ReadLock(_ReadWriteLock):
    def __init__(self, name, client) -> None:
        super().__init__(name, client)
        self.read_lock = Lock(name=f"{name}-read", client=client)
        self.count_var = Variable(name=f"{name}-count", client=client)

    async def acquire(self):
        async with self.read_lock:
            count = await self.count_var.get() or 0  # blocks
            count = count + 1
            await self.count_var.set(count)
            if count == 1:
                await self.write_lock.acquire()

    async def release(self):
        async with self.read_lock:
            count = await self.count_var.get()
            count = count - 1
            if count == 0:
                self.count_var.delete()
                await self.write_lock.release()
            else:
                await self.count_var.set(count)


class WriteLock(_ReadWriteLock):
    async def acquire(self):
        await self.write_lock.acquire()

    async def release(self):
        await self.write_lock.release()

You should be able to call Variable.get with a timeout to check if it is set.

Then maybe something else is at play here then, if that's the expected behaviour. If I put a set before my get call things start working (though I run into problems with that set clobbering an existing value, but it does prevent get blocking.

If you want more specific feedback, it should be relatively easy to implement an is_set method which works similar to the existing get. If this is what you are looking for, would you be willing to open a PR?

I don't particularly mind what form it comes in, but just so a call to get doesn't block when the variable doesn't exist. I'm happy to do a pull request, though it maybe sounds more like this is a bug then a feature.

[jamesstidard]

You should be able to call Variable.get with a timeout to check if it is set.

Sorry, I misread what you said here. Calling with a timeout is not ideal as you cant differentiate between a slow response vs it not being set at all.

I'll take a look to see if I have find myself around the codebase to make a pull request.

[fjetter]

Why not initialize the variable to 0 such that there is always a value, removing the ambiguity?

[jamesstidard]

Why not initialize the variable to 0 such that there is always a value, removing the ambiguity?

This did cross my mind, but the names I want to use will be dynamic and high in number, so being able to predefine them would be quite hard/inefficient in this context. Though this is actually the kind of work around I have at the moment; I create a single dictionary at start up and then have the dynamic names as keys. Though this is also not ideal as I have to lock access to the entire dictionary, instead of just the names.

I made a pull request adding a Varaible.is_set method, as you suggests. #5835

[fjetter]

so being able to predefine them would be quite hard/inefficient in this context

regarding efficiency, it won't be more inefficient than checking if the variable is set every time. I would prefer initializing every Variable once instead of verifying if it is initialised on every invocation.

• initialization is one request per Variable instance
• verification will require one request per acquire call, i.e. double the number of requests for every acquire

[jamesstidard]

regarding efficiency, it won't be more inefficient than checking if the variable is set every time. I would prefer initializing every Variable once instead of verifying if it is initialised on every invocation.

• initialization is one request per Variable instance
• verification will require one request per acquire call, i.e. double the number of requests for every acquire

Yeah, that's all true. Appreciate the suggestion.

I can't be certain about all the variables needed at run time though, and I don't want to have to create all the variables which may never need to be used. Also, if I went down that route, I'd need to be making these variables in other areas of the code which don't have context of dask related things, and I would prefer to not do that, personally.

Sorry, I'm trying to resisting giving you paragraphs on my specific use case. Though I can if there is some concern of if the new function should be introduced at all to the dask code base.

An alternative solution, which maybe satisfies both of us (re: doubling the number of requests) would be to:

1. Change the behaviour or Variable.get to return a KeyError or None when unset instead of waiting. Breaking change.
2. The above, but that behaviour is controlled by a new optional argument, defaulting to waiting. Not breaking change.
3. Additional default argument to Variable.get which if past will be returned instead of waiting when not set. Not breaking change.
4. Adding a Variable.setdefualt similar to dict.setdefault in addition to the Variable.get and Variable.set options currently. This wouldn't actually address the double calls in my specific use case.

Personally, I feel number 3 would be the best. Similar to dict.get(name, default) Something like:

# number 3
var = Variable("x")
_ = await var.get(0)  
# or
_ = await var.get(default=0)

This would not set the vale on call, but just instantly return with that default value, letting the user set I if they want to.