4 ms·

> The difference between this and the old Atomics is that here, when a CAS fails due to contention, instead of spinning the CPU, the Adder will store the delta

> The difference between this and the old Atomics is that here, when a CAS fails due to contention, instead of spinning the CPU, the Adder will store the delta in an internal cell object allocated for that thread. Wow man Java's still all in with it's terrible threading mechanism all the while C# has had async, await and parallelism for years, Go is well past version 1 to great acclaim, node.js and libuv are taking over, and Akka has gained enormous popularity and yet real coroutines in Java aren't even on the horizon. Even python 3 is getting coroutines. Low level threads in Java are so goddamned awful and unavoidable that it makes me want to pull my hair out. And I otherwise love Java. Java would be so awesome with real, native coroutines. Like that should be only thing they should be working on right now. Edit: I'm guessing the people downvoting this have no idea what I'm talking about and don't know what coroutines are. You know I'm starting to think there's maybe an entire generation of Java engineers who have no idea how much easier it is to write concurrent code with other tools and Java has ruined them. I love Java, but expand your horizons a bit.

eranation 12y ago
You have librarires such as https://github.com/kilim/kilim https://github.com/kilim/kilim or http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ for Java lightweight threads
- leorocky 12y ago
  Yeah there are some nice libraries, my preference is Akka, but I think Java needs real native coroutines: https://en.wikipedia.org/wiki/Coroutine https://en.wikipedia.org/wiki/Coroutine https://en.wikipedia.org/wiki/Coroutine#Implementations_for_Java https://en.wikipedia.org/wiki/Coroutine#Implementations_for_...
  - eranation 12y ago
    Akka doesn't have native coroutines / lightweight threads, it relies on regular JVM threads. it does reuse them for Actors but it dons't do the same things as Qasar (user level threads via bytecode instrumentation). I'm a big Scala and Akka fan, but thought it's worth noting.
    - leorocky 12y ago
      Akka is a library not an extension of the JVM so it would not be able to provide native features to Java. I didn't know that Quasar did more. One is able to write much better concurrent code with Akka than with vanilla Java but I think you can still run into threading issues where Java makes this unavoidable, like when playing with audio.
    - eeperson 12y ago
      Quasar also relies on JVM threads. Akka's lightweight actors are just as native as Quasar's lightweight threads.
      - pron 12y ago
        (main Quasar author): Akka actors are nothing like Quasar fibers (or even Quasar actors). Quasar provides true lightweight threads - though they're not "native" to the JVM, they're as real as Erlang's processes or Go's goroutines - while Akka actors are a formal way to organize asynchronous callbacks.
kasey_junk 12y ago
Atomics vs Adders aren't part of the thread mechanism. They are lower level abstractions around CAS operations, that you mostly only need care about during concurrent coding. I haven't looked at the C# async implementation, but I'd bet it uses CAS operations. Further C# most certainly has similar abstractions around CAS. Akka also is written using CAS abstractions. Just because there are libraries that provide higher level abstractions around concurrent programming doesn't mean that lower level primitives aren't necessary. In fact, on the JVM due to it's abstraction away from the underlying machine, these sorts of primitives are more needed.
- leorocky 12y ago
  If you are doing concurrent programming right you don't need compare and sweep synchronization because you aren't sharing memory across different threads. One must use atomics in Java actually quite a bit, like if you wanted a sane counter. Sharing memory across threads in Java is currently unavoidable, even when there are great libraries around. For example any kind of UI or audio or file reading and writing, or timers require having to deal with low level threads.
  - saryant 12y ago
    kasey_junk's point was that you need CAS primitives (and other low-level threading operations) in order to implement higher-level concurrency abstractions like Akka on the JVM.
  - bad_user 12y ago
    > If you are doing concurrent programming right you don't need compare and sweep synchronization because you aren't sharing memory across different threads. By definition, you aren't doing concurrent programming if you aren't doing shared writes.
    - leorocky 12y ago
      > By definition, you aren't doing concurrent programming if you aren't doing shared writes. I don't understand what you mean but I like Robert Pike's take on concurrency: "concurrency is the composition of independently executing processes"[1] As a specific example if you don't want code to block while you're waiting for HTTP requests to finish you're going to be writing concurrent code. I don't understand how that involves "shared writes" but maybe you can explain further? I can write concurrent code that shares no memory, and I can print log statements that show me it's executing concurrently, so I think you may be mistaken. [1] http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism
rdtsc 12y ago
>node.js and libuv are taking over, and Akka has gained enormous popularity and yet real coroutines in Java aren't even on the horizon There is something like that for Java http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ Android has async-like abstractions in its API. But I like threads better anyway. > Wow man Java's still all in with it's terrible threading mechanism all the while C# has had async What is so bad about threads? Why do you need co-routines?
- leorocky 12y ago
  > What is so bad about threads? Why do you need co-routines? You aren't forced into sharing memory across parts of your program that have no business sharing memory. In Java you can easily end up in a situation where you can look at a program and not know what thread one line is executing in versus another line in the same file. The same instance of a class may be referencing one of its property in one thread or another, and that's sharing memory across threads. A simple if statement may fail you when you share memory across threads because after the if statement checking shared memory evaluates the underlying value for that property it may have changed before the next lines after your if statement executes. Coroutines as they exist in Go or C# help programmers write code that don't share memory across threads. Akka does this, try it, it's amazing. Java needs native support. Threads are shit. Sharing memory across threads is a nightmare. Edit: If you're going to downvote, explain why I'm wrong.
  - wcummings 12y ago
    Coroutines also share process space, they're just deterministic so you don't need locks as frequently. The real benefit is lower overhead in terms of memory use, creation and task switching.
  - rdtsc 12y ago
    > You aren't forced into sharing memory across parts of your program that have no business sharing memory. I think you are confused (but I didn't downvote you, someone did and then also downvoted my post, was it you ;-) ) Anyway. Unless you use Erlang or fork OS processes you will be sharing memory between your concurrency units. So learn Erlang it will do you good http://learnyousomeerlang.com/content http://learnyousomeerlang.com/content You can build java threads with queues and that works fine. You can shoot yourself in the foot with Go or node.js (probably more so).
pron 12y ago
First, Java has fibers[1]. Second, Adder has nothing to do with that. It's a low-level concurrency construct, that many languages would be happy to have. It doesn't matter if you use kernel threads or fibers, concurrent data structures are a great tool, and Java leads the way in that area. [1]: http://blog.paralleluniverse.co/2014/05/01/modern-java/ http://blog.paralleluniverse.co/2014/05/01/modern-java/
bad_user 12y ago
> C# has had async, await and parallelism for years For Scala developers, there's Scala Async, which is exactly what C# "async" is, implemented as a library: https://github.com/scala/async https://github.com/scala/async - plus Scala's `Future[T]` has a better design than C#'s Task. > node.js and libuv are taking over And both suck in comparison with Java's NIO and the libraries that have been built on top of it. > Low level threads in Java are so goddamned awful and unavoidable that it makes me want to pull my hair out Low level concurrency primitives are necessary for building higher-level abstractions on top. For example I need low level concurrency primitives for implementing a Reactive Extensions (Rx) implementation that does back-pressure: https://github.com/alexandru/monifu/ https://github.com/alexandru/monifu/ > the people downvoting this have no idea what I'm talking about and don't know what coroutines are You're assuming too much.
- deleted 12y ago
  [deleted]
  - deleted 12y ago
    [deleted]
- Locke1689 12y ago
  plus Scala's `Future[T]` has a better design than C#'s Task Why? The one issue I have with Task is the aggravating SynchronizationContext/continueOnCapturedContext. ConfigureAwait(false) really should have been the default. Otherwise, my experience with both seems about equivalent.
scott_s 12y ago
You're getting downvoted because your post is "middlebrow dismissal" (https://news.ycombinator.com/item?id=5072224 https://news.ycombinator.com/item?id=5072224) which is also unnecessarily aggressive. It's quite possible for someone to know exactly what you are talking about, and still downvote it. Regarding the technical points, having low-level mechanisms for fine-grained synchronization between threads (such as these) does not prevent you from also providing high-level mechanisms for parallelism and concurrency. In fact, it enables others to develop such abstractions in that language in question, without relying on the language itself to provide them.
- leorocky 12y ago
  > unnecessarily aggressive Aggression that's really the result of thread frustration in Java. I hadn't read about middlebrow dismissal before, I can see how my post came off wrong. I'm glad I posted what I said however, because I the responses taught me new things.
  - rdtsc 12y ago
    I think you can be aggressive (heck look at Linus) but it has to be substantiate by in detail knowledge and arguments. If you are aggressive then make wrong statements (co-routines not sharing memory) then well you'll get downvoted. I guess take that as life advice in general.
    - leorocky 12y ago
      > If you are aggressive then make wrong statements (co-routines not sharing memory) then well you'll get downvoted. My point was that a programmer shouldn't need to share memory to write concurrent code. That statement is not wrong.
      - rdtsc 12y ago
        > That statement is not wrong. Yes it is. Unless you use Erlang or OS processes you are sharing memory. Or rather you not sharing it any more or less than all the other technologies you listed. But I agree with your sentiment in general that shared memory and concurrency are not working well. That is why it is worthwhile learning Erlang if you want to be reliable, fault tolerant concurrent systems. Also nothings stops your from using queues and threads so data is local to each thread and gets copied over the queue.
xxs 12y ago
Adders were easily implementable and readily available pre-Java8, basically they need the new JMM from java5 on (i.e 10+ years). Hence, no really a hot topic, yet very nice to have. However any serious project already had something of the sort. On the other topic: async/coroutines/friends etc have nothing to do with "adders". The latter are a low-level concurrency primitives that enable fast counters and the like. Feel challenged to write a good a simple counter (like page hit) with co-routines or sync.

eranation 12y ago

You have librarires such as https://github.com/kilim/kilim https://github.com/kilim/kilim or http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ for Java lightweight threads

leorocky 12y ago
Yeah there are some nice libraries, my preference is Akka, but I think Java needs real native coroutines: https://en.wikipedia.org/wiki/Coroutine https://en.wikipedia.org/wiki/Coroutine https://en.wikipedia.org/wiki/Coroutine#Implementations_for_Java https://en.wikipedia.org/wiki/Coroutine#Implementations_for_...
- eranation 12y ago
  Akka doesn't have native coroutines / lightweight threads, it relies on regular JVM threads. it does reuse them for Actors but it dons't do the same things as Qasar (user level threads via bytecode instrumentation). I'm a big Scala and Akka fan, but thought it's worth noting.
  - leorocky 12y ago
    Akka is a library not an extension of the JVM so it would not be able to provide native features to Java. I didn't know that Quasar did more. One is able to write much better concurrent code with Akka than with vanilla Java but I think you can still run into threading issues where Java makes this unavoidable, like when playing with audio.
  - eeperson 12y ago
    Quasar also relies on JVM threads. Akka's lightweight actors are just as native as Quasar's lightweight threads.
    - pron 12y ago
      (main Quasar author): Akka actors are nothing like Quasar fibers (or even Quasar actors). Quasar provides true lightweight threads - though they're not "native" to the JVM, they're as real as Erlang's processes or Go's goroutines - while Akka actors are a formal way to organize asynchronous callbacks.

kasey_junk 12y ago

Atomics vs Adders aren't part of the thread mechanism. They are lower level abstractions around CAS operations, that you mostly only need care about during concurrent coding. I haven't looked at the C# async implementation, but I'd bet it uses CAS operations. Further C# most certainly has similar abstractions around CAS. Akka also is written using CAS abstractions. Just because there are libraries that provide higher level abstractions around concurrent programming doesn't mean that lower level primitives aren't necessary. In fact, on the JVM due to it's abstraction away from the underlying machine, these sorts of primitives are more needed.

leorocky 12y ago
If you are doing concurrent programming right you don't need compare and sweep synchronization because you aren't sharing memory across different threads. One must use atomics in Java actually quite a bit, like if you wanted a sane counter. Sharing memory across threads in Java is currently unavoidable, even when there are great libraries around. For example any kind of UI or audio or file reading and writing, or timers require having to deal with low level threads.
- saryant 12y ago
  kasey_junk's point was that you need CAS primitives (and other low-level threading operations) in order to implement higher-level concurrency abstractions like Akka on the JVM.
- bad_user 12y ago
  > If you are doing concurrent programming right you don't need compare and sweep synchronization because you aren't sharing memory across different threads. By definition, you aren't doing concurrent programming if you aren't doing shared writes.
  - leorocky 12y ago
    > By definition, you aren't doing concurrent programming if you aren't doing shared writes. I don't understand what you mean but I like Robert Pike's take on concurrency: "concurrency is the composition of independently executing processes"[1] As a specific example if you don't want code to block while you're waiting for HTTP requests to finish you're going to be writing concurrent code. I don't understand how that involves "shared writes" but maybe you can explain further? I can write concurrent code that shares no memory, and I can print log statements that show me it's executing concurrently, so I think you may be mistaken. [1] http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism

rdtsc 12y ago

>node.js and libuv are taking over, and Akka has gained enormous popularity and yet real coroutines in Java aren't even on the horizon There is something like that for Java http://docs.paralleluniverse.co/quasar/ http://docs.paralleluniverse.co/quasar/ Android has async-like abstractions in its API. But I like threads better anyway. > Wow man Java's still all in with it's terrible threading mechanism all the while C# has had async What is so bad about threads? Why do you need co-routines?

leorocky 12y ago
> What is so bad about threads? Why do you need co-routines? You aren't forced into sharing memory across parts of your program that have no business sharing memory. In Java you can easily end up in a situation where you can look at a program and not know what thread one line is executing in versus another line in the same file. The same instance of a class may be referencing one of its property in one thread or another, and that's sharing memory across threads. A simple if statement may fail you when you share memory across threads because after the if statement checking shared memory evaluates the underlying value for that property it may have changed before the next lines after your if statement executes. Coroutines as they exist in Go or C# help programmers write code that don't share memory across threads. Akka does this, try it, it's amazing. Java needs native support. Threads are shit. Sharing memory across threads is a nightmare. Edit: If you're going to downvote, explain why I'm wrong.
- wcummings 12y ago
  Coroutines also share process space, they're just deterministic so you don't need locks as frequently. The real benefit is lower overhead in terms of memory use, creation and task switching.
- rdtsc 12y ago
  > You aren't forced into sharing memory across parts of your program that have no business sharing memory. I think you are confused (but I didn't downvote you, someone did and then also downvoted my post, was it you ;-) ) Anyway. Unless you use Erlang or fork OS processes you will be sharing memory between your concurrency units. So learn Erlang it will do you good http://learnyousomeerlang.com/content http://learnyousomeerlang.com/content You can build java threads with queues and that works fine. You can shoot yourself in the foot with Go or node.js (probably more so).

pron 12y ago

First, Java has fibers[1]. Second, Adder has nothing to do with that. It's a low-level concurrency construct, that many languages would be happy to have. It doesn't matter if you use kernel threads or fibers, concurrent data structures are a great tool, and Java leads the way in that area. [1]: http://blog.paralleluniverse.co/2014/05/01/modern-java/ http://blog.paralleluniverse.co/2014/05/01/modern-java/

bad_user 12y ago

> C# has had async, await and parallelism for years For Scala developers, there's Scala Async, which is exactly what C# "async" is, implemented as a library: https://github.com/scala/async https://github.com/scala/async - plus Scala's `Future[T]` has a better design than C#'s Task. > node.js and libuv are taking over And both suck in comparison with Java's NIO and the libraries that have been built on top of it. > Low level threads in Java are so goddamned awful and unavoidable that it makes me want to pull my hair out Low level concurrency primitives are necessary for building higher-level abstractions on top. For example I need low level concurrency primitives for implementing a Reactive Extensions (Rx) implementation that does back-pressure: https://github.com/alexandru/monifu/ https://github.com/alexandru/monifu/ > the people downvoting this have no idea what I'm talking about and don't know what coroutines are You're assuming too much.

deleted 12y ago
[deleted]
- deleted 12y ago
  [deleted]
Locke1689 12y ago
plus Scala's `Future[T]` has a better design than C#'s Task Why? The one issue I have with Task is the aggravating SynchronizationContext/continueOnCapturedContext. ConfigureAwait(false) really should have been the default. Otherwise, my experience with both seems about equivalent.

scott_s 12y ago

You're getting downvoted because your post is "middlebrow dismissal" (https://news.ycombinator.com/item?id=5072224 https://news.ycombinator.com/item?id=5072224) which is also unnecessarily aggressive. It's quite possible for someone to know exactly what you are talking about, and still downvote it. Regarding the technical points, having low-level mechanisms for fine-grained synchronization between threads (such as these) does not prevent you from also providing high-level mechanisms for parallelism and concurrency. In fact, it enables others to develop such abstractions in that language in question, without relying on the language itself to provide them.

leorocky 12y ago
> unnecessarily aggressive Aggression that's really the result of thread frustration in Java. I hadn't read about middlebrow dismissal before, I can see how my post came off wrong. I'm glad I posted what I said however, because I the responses taught me new things.
- rdtsc 12y ago
  I think you can be aggressive (heck look at Linus) but it has to be substantiate by in detail knowledge and arguments. If you are aggressive then make wrong statements (co-routines not sharing memory) then well you'll get downvoted. I guess take that as life advice in general.
  - leorocky 12y ago
    > If you are aggressive then make wrong statements (co-routines not sharing memory) then well you'll get downvoted. My point was that a programmer shouldn't need to share memory to write concurrent code. That statement is not wrong.
    - rdtsc 12y ago
      > That statement is not wrong. Yes it is. Unless you use Erlang or OS processes you are sharing memory. Or rather you not sharing it any more or less than all the other technologies you listed. But I agree with your sentiment in general that shared memory and concurrency are not working well. That is why it is worthwhile learning Erlang if you want to be reliable, fault tolerant concurrent systems. Also nothings stops your from using queues and threads so data is local to each thread and gets copied over the queue.

xxs 12y ago

Adders were easily implementable and readily available pre-Java8, basically they need the new JMM from java5 on (i.e 10+ years). Hence, no really a hot topic, yet very nice to have. However any serious project already had something of the sort. On the other topic: async/coroutines/friends etc have nothing to do with "adders". The latter are a low-level concurrency primitives that enable fast counters and the like. Feel challenged to write a good a simple counter (like page hit) with co-routines or sync.