maas-devel team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On 03/05/14 00:46, Jeroen Vermeulen wrote:
> On 05/01/2014 02:37 AM, Julian Edwards wrote:
> 
>>> And what would we be waiting for?  If the node is locked, it's probably
>>> because someone else is already allocating it.
>>
>> Not necessarily, and if that is the case then when the locked thread is
>> freed it won't see the allocated node due to the query filtering.
> 
> Looks like we have different ways of doing this in mind.  You seem to be
> thinking of doing a select-for-update query to find the first available
> match, and either block or retry if the query gives you a locked node.
> 
> I was thinking to do the filtering just once without lock, and then walk
> through the result to find a candidate that we can lock, and once we do,
> we check if it's still available.
> 
> That way, there's no waiting at all for locked nodes.  If another client
> holds a lock on one of the candidates, we just move on to the next.

I think your way is OK, but seems like an early optimisation.

If a node is locked but would be available when freed, and no other
nodes are available, what will your method do given that it is yet to
consider all possible nodes?  Go back to blocking?