4 ms·

Lightweight threads (fibers) looks especially interesting to me. I wonder if there is some library that already tries to ger around threads with something more

by haddr 12y ago

Lightweight threads (fibers) looks especially interesting to me. I wonder if there is some library that already tries to ger around threads with something more lightweight...

norswap 12y ago
Assuming this is not rhetorical; yes there is: http://www.paralleluniverse.co/quasar/ http://www.paralleluniverse.co/quasar/
tormeh 12y ago
http://akka.io/ http://akka.io/
- eranation 12y ago
  I love Akka, but I thought their implementation relies on regular JVM threads at the moment, isn't it? (I had a wishful thinking at first that they are using user-threads at first, but they are not like quasar or goroutines in any way from what I read, Actors might reuse threads and seem like a "lighter thread" but they are still using plain old JVM threads, for now at least)
  - tormeh 12y ago
    Correct. Like goroutines, but even lighter, as they have no stack. Java threads map directly to OS threads, do they not?
  - eeperson 12y ago
    I'm not sure I understand what distinction you are making. All of the examples you mention are built by reusing OS/JVM threads. That is how you have to implement user-threads. How do you feel Akka differs from Quasar/Go (aside from the coroutine/actor distinction) .
    - eranation 12y ago
      Quasar uses byte code instrumentation to do things you can't do with "regular" java. How exactly they can do things whne the JVM is the same JVM? good question, I don't know, I know implementing user threads simply means keeping stack information, keeping a scheduler, handling signals, without asking the kernel / OS for a native thread (had to implement user threads in C in the past, not fun) Maybe the JVM allows for more fine grained control on PC location, and allows to "go to" different places in the code without invoking a native thread. But I know that when you create a Quasar co-routine / green thread / user thread / continuation or whatever we want to call it, then it's not the same as Akka. In Akka, if you have a "conversation" between a million actors in a circle, you can still get 1 thread to be reused, if there is no need to use more than one. But if you try to do 3 things in 100% parallel, you might find yourself with 3 threads (from the little that I know). In quasar, you can do all that, without invoking an OS thread, I think this is the main difference. http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/
x0x0 12y ago
fj / jsr166 is in 7 sample code: http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html http://docs.oracle.com/javase/tutorial/essential/concurrency...
rdtsc 12y ago
An interesting one is http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ They claim to have "true lightweight" threads. (I am sure pron if he is a around can jump in and expand on it). It takes a lot from Erlang even pattern matching.
- pron 12y ago
  Well, the pattern matching is only in the Clojure API, but yeah, these are true fibers based on continuations implemented with bytecode instrumentation, scheduled by a work stealing scheduler (or any other scheduler of your choice). It lets you write simple blocking code with all its familiarity and advantages (exceptions, thread-local data) but enjoy the performance of async code. The downside is that libraries have to be integrated in order to block gracefully when called on fibers, but we already have a long and growing list of integration modules for popular libraries.
justinsb 12y ago
I would love to see threads based on this work (OS support for lightweight threads): http://www.linuxplumbersconf.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf http://www.linuxplumbersconf.org/2013/ocw//system/presentati... It seems this would move most of the heavy lifting into the kernel (and out of the already-very-complicated JVM). Anyone know what happened to that work?
- pron 12y ago
  AFAIK, Google uses it (to some extent, at least), but the solution suffers some issues that make it less than ideal. While it relinquishes scheduling to the application, stack management remains the kernel responsibility, so while the task-switching overhead is greatly reduced, the threads are still not quite lightweight. The advantages to the approach is that it automatically crosses "language barriers", say, between the JVM and native code. This is very important for Google, who use C++ libraries as common code in their polyglot projects, but maybe not so important in other shops.

by haddr 12y ago

Lightweight threads (fibers) looks especially interesting to me. I wonder if there is some library that already tries to ger around threads with something more lightweight...

norswap 12y ago

Assuming this is not rhetorical; yes there is: http://www.paralleluniverse.co/quasar/ http://www.paralleluniverse.co/quasar/

tormeh 12y ago

http://akka.io/ http://akka.io/

eranation 12y ago
I love Akka, but I thought their implementation relies on regular JVM threads at the moment, isn't it? (I had a wishful thinking at first that they are using user-threads at first, but they are not like quasar or goroutines in any way from what I read, Actors might reuse threads and seem like a "lighter thread" but they are still using plain old JVM threads, for now at least)
- tormeh 12y ago
  Correct. Like goroutines, but even lighter, as they have no stack. Java threads map directly to OS threads, do they not?
- eeperson 12y ago
  I'm not sure I understand what distinction you are making. All of the examples you mention are built by reusing OS/JVM threads. That is how you have to implement user-threads. How do you feel Akka differs from Quasar/Go (aside from the coroutine/actor distinction) .
  - eranation 12y ago
    Quasar uses byte code instrumentation to do things you can't do with "regular" java. How exactly they can do things whne the JVM is the same JVM? good question, I don't know, I know implementing user threads simply means keeping stack information, keeping a scheduler, handling signals, without asking the kernel / OS for a native thread (had to implement user threads in C in the past, not fun) Maybe the JVM allows for more fine grained control on PC location, and allows to "go to" different places in the code without invoking a native thread. But I know that when you create a Quasar co-routine / green thread / user thread / continuation or whatever we want to call it, then it's not the same as Akka. In Akka, if you have a "conversation" between a million actors in a circle, you can still get 1 thread to be reused, if there is no need to use more than one. But if you try to do 3 things in 100% parallel, you might find yourself with 3 threads (from the little that I know). In quasar, you can do all that, without invoking an OS thread, I think this is the main difference. http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/

x0x0 12y ago

fj / jsr166 is in 7 sample code: http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html http://docs.oracle.com/javase/tutorial/essential/concurrency...

rdtsc 12y ago

An interesting one is http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ They claim to have "true lightweight" threads. (I am sure pron if he is a around can jump in and expand on it). It takes a lot from Erlang even pattern matching.

pron 12y ago
Well, the pattern matching is only in the Clojure API, but yeah, these are true fibers based on continuations implemented with bytecode instrumentation, scheduled by a work stealing scheduler (or any other scheduler of your choice). It lets you write simple blocking code with all its familiarity and advantages (exceptions, thread-local data) but enjoy the performance of async code. The downside is that libraries have to be integrated in order to block gracefully when called on fibers, but we already have a long and growing list of integration modules for popular libraries.

justinsb 12y ago

I would love to see threads based on this work (OS support for lightweight threads): http://www.linuxplumbersconf.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf http://www.linuxplumbersconf.org/2013/ocw//system/presentati... It seems this would move most of the heavy lifting into the kernel (and out of the already-very-complicated JVM). Anyone know what happened to that work?

pron 12y ago
AFAIK, Google uses it (to some extent, at least), but the solution suffers some issues that make it less than ideal. While it relinquishes scheduling to the application, stack management remains the kernel responsibility, so while the task-switching overhead is greatly reduced, the threads are still not quite lightweight. The advantages to the approach is that it automatically crosses "language barriers", say, between the JVM and native code. This is very important for Google, who use C++ libraries as common code in their polyglot projects, but maybe not so important in other shops.