Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  A new Java lightweight thread library  (Read 2537 times)
0 Members and 1 Guest are viewing this topic.
Offline pron

Junior Member


Medals: 4



« Posted 2013-05-03 00:55:10 »

I discovered Matthias Mann's continuations library when Riven showcased it on these forums. I then put (a modified version of) it on top of fork/join and the result was  Quasar: https://github.com/puniverse/quasar. If you're interested, you can read about Quasar, and its Clojure API, Pulsar, in this blog post: http://blog.paralleluniverse.co/post/49445260575/quasar-pulsar
Offline actual

JGO Coder


Medals: 23



« Reply #1 - Posted 2013-05-03 02:04:01 »

Interesting stuff. I see in your blog post the code examples are in clojure. Do you have equivalent examples in Java?
Offline Spasi
« Reply #2 - Posted 2013-05-03 03:07:40 »

Nice read.

Have you considered using the Disruptor for your queues? Unbounded queues enable simpler APIs but are almost always a bad idea. Just copy the behavior of Go's channels; no capacity and you get a SynchronizedQueue, otherwise you get a bounded queue. You should be able to emulate a SynchronizedQueue using the Disruptor, then you only have to document that capacity has to be a power-of-2. But I guess you already require that in your bounded queue implementation.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pron

Junior Member


Medals: 4



« Reply #3 - Posted 2013-05-03 16:15:23 »

Do you have equivalent examples in Java?

There are some Java examples pointed out on the project's page.
You'll find links there to the documentation, too, when it's ready.

Have you considered using the Disruptor for your queues?

The bounded queues are implemented very similarly to the disruptor. Are you suggesting one disruptor to replace all queues? If so, I don't think the disruptor would make a good choice. The disruptor especially shines when you have one producer and multiple consumers (each consumer updates a non-shared index to the last read item, while the producer simply needs to increment a volatile index to mark the last entry written). In fact, if you've seen the original LMAX talk, that's precisely what the disruptor was designed for. But here the problem is the opposite: we have multiple producers but only a single consumer.
Offline actual

JGO Coder


Medals: 23



« Reply #4 - Posted 2013-05-03 17:18:52 »

pron,

Thanks, I'm not sure how I missed it. I look forward to playing with it.

spasi,

Thanks to the pointer to Disruptor. I haven't heard of it before.
Offline Spasi
« Reply #5 - Posted 2013-05-03 17:42:58 »

But here the problem is the opposite: we have multiple producers but only a single consumer.

Disruptor development, after the initial release, was mostly driven by exactly this case, multiple producers. Even as early as when instantiating a RingBuffer you have to choose between the two major use cases, see the createSingleProducer and createMultiProducer methods. The MultiProducerSequence class is what takes care of multi-thread publishing in the current version.
Offline pron

Junior Member


Medals: 4



« Reply #6 - Posted 2013-05-04 03:07:00 »

Disruptor development, after the initial release, was mostly driven by exactly this case, multiple producers. Even as early as when instantiating a RingBuffer you have to choose between the two major use cases, see the createSingleProducer and createMultiProducer methods. The MultiProducerSequence class is what takes care of multi-thread publishing in the current version.

Yes, but even in that case, the disruptor only helps when you have multiple consumers. For multiple producers the disruptor does the only thing that can be done: a CAS on each insert. The whole idea behind the disruptor was improving the reads, not the writes. Having each consumer hold its own index into the queue and not having the consumers write contended variables is the disruptor's contribution. If you have a single consumer, there's no contention on the read side anyway.

In short, in the single-consumer multiple-producer case, the disruptor is identical to the bounded queue used in Quasar.
Offline Spasi
« Reply #7 - Posted 2013-05-04 13:32:41 »

That's my point, isn't it better to use a proven solution instead of rolling your own? You also get batch processing, configurable wait strategies and dependency chaining out of the box.

the disruptor only helps when you have multiple consumers.

I don't see the point of what you're saying. It's obvious that it's not as fast compared to having a single producer, but it's many times faster than an JDK BlockingQueue in the multi-producer case. CAS-on-insert is much better than a lock and it's not the only thing that the Disruptor gets right (PoT size to avoid divisions, false-sharing elimination, etc, you do these things in your implementation too).
Offline pron

Junior Member


Medals: 4



« Reply #8 - Posted 2013-05-04 19:01:20 »

That's my point, isn't it better to use a proven solution instead of rolling your own? You also get batch processing, configurable wait strategies and dependency chaining out of the box.

Maybe you're right. I don't know, it just seemed like a bit of an overkill if all I needed was one consumer. I didn't need dependency chaining and configurable wait strategies, and the only wait strategy I needed wan't supported by the disruptor anyway -- fiber-blocking -- so I would have had to do that myself. Also, I wanted to have primitive-type bounded queues, and unbounded queues, too, so an existing solution for one specific type of queue wouldn't have saved much work. You can look at my implementation here and here. It's about 300 lines in total. Primitive queues require a bit more work. See here and here. (Those are just the bounded queues).

Actually, I just remembered, there was one tricky issue here. The consumer holds a pointer to the last item it read in the queue (I use this for selective receives), and because I use both bounded and unbounded queues, that pointer could be either an index or a ref to a linked-list node, so it's gotta be an Object. In the bounded queue case, Martin's queue uses a long index which always increases; the actual index in the array is that index mod the array length. That meant that any time the consumer read a value, a boxed long would have had to be created and could have been held for a long time (i.e., could be promoted GC-wise). I do something a bit ugly. Internally I use Martin's long-index approach, but I give the consumer an int index, which is equal to the actual array index. This keeps the index always to a small int (always less than the size of the array), so increasing Integer's default maximal cached Integer by just a bit, ensures that a the boxed Integer instance is always cached.
Offline pron

Junior Member


Medals: 4



« Reply #9 - Posted 2013-10-16 17:54:59 »

We've re-written our spaceships demo to use Quasar's lightweight Java threads. You can read about it here: http://blog.paralleluniverse.co/post/64210769930/spaceships2.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (24 views)
2014-07-24 01:59:36

Riven (24 views)
2014-07-23 21:16:32

Riven (18 views)
2014-07-23 21:07:15

Riven (21 views)
2014-07-23 20:56:16

ctomni231 (50 views)
2014-07-18 06:55:21

Zero Volt (45 views)
2014-07-17 23:47:54

danieldean (36 views)
2014-07-17 23:41:23

MustardPeter (39 views)
2014-07-16 23:30:00

Cero (54 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!