Problems with Memory-Channel-based ring implementation

21 wyświetleń
Przejdź do pierwszej nieodczytanej wiadomości

kaeluka

nieprzeczytany,
7 lut 2012, 10:36:097.02.2012
do jetlang-dev
Hello, I have got some problems to make a small prototype of mine run
smoothly.

I want to send a token (type Integer) around a circle of fibers, each
fiber hands the message, decreased by one on to the next fiber via
publishing it to its MemoryChannel (called "Out"). The next fiber has
subscribed to that channel. So it's a linked, circular list. A fairly
standard example, I suppose.

My code is here: https://github.com/kaeluka/Jetlang-Ring/

(look in ring/RingElem.java for the implementation of the Item that
passes the token on to the next one)

As you can see, there is a
"private static PoolFiberFactory factory" -- if I use a fiber that is
generated from that factory, my program runs like expected: the token
gets passed around and once it reaches zero, the JVM terminates
(because of the System.exit).

Now to the problem:
If I use a ThreadFiber instead of a Factory-generated Fiber, the
program runs for a couple of lines of output and then suddenly
*terminates*. The number of successful transmissions is different
every time I run it (and I have to feeling that it might depend on
your hardware, too).

The output looks like this:

.../Jetlang-Ring $ make run
javac -g ring/RingElem.java
java proto
RingElem 1 received 500000
RingElem 2 received 499999
RingElem 3 received 499998
RingElem 4 received 499997
RingElem 5 received 499996
RingElem 6 received 499995
RingElem 7 received 499994
RingElem 8 received 499993
RingElem 9 received 499992
RingElem 10 received 499991
RingElem 11 received 499990
RingElem 12 received 499989
RingElem 13 received 499988
RingElem 14 received 499987
.../Jetlang-Ring $

so I guess, all threads have died? Since none of them was a daemon and
the JVM exited? But why? Debugging did not get me far, sadly, but that
might be attributed to myself; I'm a relative beginner to OOP
concurrency and didn't use java in years..
Wiadomość została usunięta

kaeluka

nieprzeczytany,
7 lut 2012, 10:47:147.02.2012
do jetlang-dev
Oh, and I should add: I'm running this on Ubuntu 10.10 with
$ java -version
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.10)
(6b20-1.9.10-0ubuntu1~10.10.3)
OpenJDK Client VM (build 19.0-b09, mixed mode, sharing)

kaeluka

nieprzeczytany,
8 lut 2012, 10:56:548.02.2012
do jetlang-dev
I was able to solve it: the problem was that all the RingElem threads
where started as daemon threads (which is the behaviour of
ThreadFiber's standard ctor). Because of this, the VM ended, once the
end of public static void main was reached :)

Mike Rettig

nieprzeczytany,
8 lut 2012, 11:18:058.02.2012
do jetla...@googlegroups.com
One way to solve this in a test is to use a CountDownLatch to signal
the main thread that the test is complete. Then the main thread can
wait for the signal and keep the app alive until the completion of the
test.

Mike

> --
> You received this message because you are subscribed to the Google Groups "jetlang-dev" group.
> To post to this group, send email to jetla...@googlegroups.com.
> To unsubscribe from this group, send email to jetlang-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jetlang-dev?hl=en.
>

kaeluka

nieprzeczytany,
9 lut 2012, 09:40:069.02.2012
do jetlang-dev
Yes, I saw that class and how it is used in examples and unit tests
and will definitely use that pattern for more serious applications.

As it looks now, I'll probably will use Jetlang as underlying toolbox
to implement yet another actors-implementation in my master thesis
(which, in my case is necessary, since we are working on a flavor of
actors that doesn't exist yet).
Odpowiedz wszystkim
Odpowiedz autorowi
Przekaż
Nowe wiadomości: 0