<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 1 December 2015 at 13:40, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The current approach means locks block on their own, are processed in<br>
the order they come in, but deletes aren't possible. The busy lock would<br>
mean deletes were normal. Some extra cpu spent on waiting, and lock<br>
order processing would be non deterministic. It's trade offs, but I<br>
don't know anywhere that we are using locks as queues, so order<br>
shouldn't matter. The cpu cost on the busy wait versus the lock file<br>
cleanliness might be worth making. It would also let you actually see<br>
what's locked from the outside pretty easily.<br>
<span class="im HOEnZb"></span><br></blockquote></div><br></div><div class="gmail_extra">The cinder locks are very much used as queues in places, e.g. making delete wait until after an image operation finishes. Given that cinder can already bring a node into resource issues while doing lots of image operations concurrently (such as creating lots of bootable volumes at once) I'd be resistant to anything that makes it worse to solve a cosmetic issue.<br></div><div class="gmail_extra"><br><br><div class="gmail_signature"><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div></div>