Asynchronous locking with Vertx

[Alexander Mills]

How do you do non-blocking (async) locking with Vertx?

https://stackoverflow.com/questions/54568507/asynchronous-non-blocking-version-of-synchronized

for example:

synchronized(foo){   // this is blocking

}

-fu

[Asher Tarnopolski]

https://vertx.io/docs/vertx-core/java/#_asynchronous_locks

[Alexander Mills]

Nah I am looking for a non-blocking lock for just one thread, not across threads.

The async locking mechanism you mention:

sd.getLock("mylock", res -> {})

appears to work across threads, which means it will be less efficient.

As an aside, I don't know what "sd" is or where it comes from in the docs.

-fu

[Asher Tarnopolski]

for sd - just scroll up to the beginning of examples:
SharedData sd = vertx.sharedData();

re lock you are looking for - can you elaborate about a lock "for one thread"? you are running in a threadsafe verticle, how do you access it and from where?

[Julien Viet]

I think you can implement it fairly easily using a boolean + a List of callbacks

When you acquire the lock and the boolean is true, you set it to true otherwise you add the callback to the list.

When you release the lock, if the list is empty you set the switch the boolean back to false otherwise you pick the next element in the list and call it.

Julien

-- 
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/08a29aa8-311c-42b4-a445-53673024b460%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Mills]

Yeah with a single lock (one namespace) then flipping a boolean should be atomic.

But with multiple namespaces, you might have to use as synchronized block here or there,

But the amount of blocking each synchronized block would have to do is much less.

O/w yes I would use the callback technique you mentioned, with a queue of course.