Binding of verticles to threads

[0pt618]

Hello Vertx Community,

In "A gentle guide to asynchronous programming with Eclipse Vert.x", it is said "a regular verticle always processes events on the same thread". I also looked this thread from 2012 (https://groups.google.com/forum/#!topic/vertx/vZaabMviW00), but something is still not clear for me.

Why is it desirable for a single verticle instance to be bound to the same OS thread? I would think we just need to guarantee that a verticle instance doesn't run concurrently - this can be achieved by having the verticle use different OS thread, just not at the same time. 

So what's the purpose of restricting a verticle instance to a never-changing thread, rather than the looser requirement I state above?

Thanks all.

[Jez P]

Let me answer your question with a different question.

How would you achieve "having the verticle use different OS thread, just not at the same time"? What implications follow on from that? Start by answering those questions and then let's explore your candidate approach vs that taken by vert.x and similar other frameworks such as Akka, Reactor, etc.

[0pt618]

Hi Jez P,

I don't know. I don't have experience writing a toolkit or framework like Vert.x or Akka. But on a rereading, I'd like to clarify something. It is said in the text that "By default Vert.x attaches 2 event loops per CPU core thread." Does every verticle get bound to the same event loop? I couldn't find this stated in the same text.

If my understanding is correct on this, then I can be sure I'm on the same page, and start reasoning about the question you posed. 

Thanks.

[Jez P]

To answer your latest question:

https://github.com/vietj/vertx-materials/blob/master/src/main/asciidoc/Demystifying_the_event_loop.adoc

http://vertx.io/blog/an-introduction-to-the-vert-x-context-object/

I don't think you need to have implemented an async framework to answer the questions I asked previously, just some knowledge of Java concurrency. If you don't have this knowledge then frankly you're going to struggle with the answers you'll get.

[Julien Viet]

Hi,

when you run on the same thread you can benefit from some mechanical sympathy

the JVM does not flush/reload data for the private fields of the verticle

the JVM can optimise synchronization monitors which are not contended and perform biased locking

you can apply the single writer principle (https://mechanical-sympathy.blogspot.fr/2011/09/single-writer-principle.html)

avoid false sharing (https://en.wikipedia.org/wiki/False_sharing)

that being said, when it comes to performance "measure, don't guess", someone could write a JMH benchmark to measure this for various use case

for instance accessing a volatile field, accessing a field under a synchronization monitor.

Do the same with an array of the cache line size, with multiples of a cache lines, etc...

do the same with a plain hashmap, concurrent hasmap, etc...

--
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/f8f18fb4-8131-4e64-8045-3d86a2c27fa7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.