«

On 6/15/2012 6:33 PM, Aaron W. Hsu wrote:
> I am considering moving one of my projects from C to Java, but I am
> hoping to find a high-performance threading implementation, or something
> along the lines of libqthread, which offers Fill-Empty bit blocking and
> good cooperative lightweight threading as a library.
>[...]

Others have covered the essentials, but I'd like to raise an
eyebrow at the word "cooperative." In the usual argot, "cooperative
threading" refers to schemes where a thread runs until it chooses
to relinguish the CPU, voluntarily. This may be contrasted to
"preemptive" schemes, where an external scheduler decides which
threads will run on which CPU's and when, and may choose to evict
a running thread or start a stalled thread at any arbitrary moment.

The "collegial" nature of cooperative threading offers a degree
of calmness, and some freedom from worry about critical sections
(if you're on a uniprocessor, you may be able to avoid taking an
explicit lock to guard a critical section: Just don't yield the CPU
while you're in it). But this cooperation is fragile in the extreme,
and becomes almost completely untenable once you start assembling an
application out of classes from disparate sources. Unless you're
writing for a very tightly controlled environment where you have
audited all the components or developed them yourself -- embedded
software in a Mars rover, say -- I think "cooperative multithreading"
is too brittle for most practical applications.

If that's not what you meant by "cooperative," well, never mind.
But if it is, my advice is Don't Do That.

--
Eric Sosman
d

On 6/15/2012 8:59 PM, Aaron W. Hsu wrote:
> On Fri, 15 Jun 2012 20:19:12 -0400, Eric Sosman wrote:
>
>> Unless you're writing for a very tightly controlled environment where
>> you have audited all the components or developed them yourself --
>> embedded software in a Mars rover, say -- I think "cooperative
>> multithreading"
>> is too brittle for most practical applications.
>
> In some sense, this is the environment. I am building on top of non-
> deterministic concurrency primitives to construct deterministic models.
> In these models, I prefer to have more control over when thread
> preemption happens, as well as what lightweight threads get associated
> with what worker thread (thread pool) and similarly what worker threads
> get associated with what CPUs. This is to allow me to make more fine
> grained decisions about scheduling, which may affect cache behavior.
>
> Preemptive multi-threading is certainly the more reliable when dealing
> with a general programming interface, but since these models specifically
> constrain the problems in certain ways, I know the points at which I
> would like to preempt a thread, and I also know that preempting earlier
> or later than these points is relatively useless.
>
> Once I have a model written up in Java, I will see how things go. It is
> likely that for small scale tests I will not notice a difference in
> cooperative versus preemptive models.

Okay. Keep in mind that in Java it is very difficult to avoid
being preempted: Even if the thread you're interested in is careful
not to create new object instances, object creation in other threads
can trigger the garbage collector at pretty much any time. You may
be able to get some scheduling benefits out of a cooperative scheme,
but I doubt you'll get thread safety. Locking or the concurrency
libraries will be all but unavoidable.

--
Eric Sosman
d

On Fri, 15 Jun 2012 20:19:12 -0400, Eric Sosman
<> wrote, quoted or indirectly quoted
someone who said :

> The "collegial" nature of cooperative threading offers a degree
>of calmness, and some freedom from worry about critical sections
>(if you're on a uniprocessor, you may be able to avoid taking an
>explicit lock to guard a critical section:

that takes me back. I wrote code for a Univac 1616 military mini to
make it simulate an IBM front end communications processor. That is
exactly how it worked.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
..

On Sat, 16 Jun 2012 01:00:10 -0700, Roedy Green
<> wrote, quoted or indirectly quoted
someone who said :

>
>that takes me back. I wrote code for a Univac 1616 military mini to
>make it simulate an IBM front end communications processor. That is
>exactly how it worked.

Circa 1990 I wrote a co-operative thread package for windows for C. It
was surprisingly simple. On task switch I had to save the stack and
registers and restore another thread's stack and registers. That was
basically all there was to it.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
..

On 6/16/2012 12:51 PM, Aaron W. Hsu wrote:
> On Fri, 15 Jun 2012 21:37:32 -0400, Eric Sosman wrote:
>
>> Even if the thread you're interested in is careful not to create new
>> object instances, object creation in other threads can trigger the
>> garbage collector at pretty much any time.
>
> The garbage collector is one of the reasons that I have hesitated to move
> to Java. In some languages (Chez Scheme) I can get quite explicit
> control over when and how garbage collection occurs, which can make it
> possible to do very fine grained things to avoid some of the corner case
> problems that can manifest in garbage collected languages. Usually this
> is not a problem at all, but I would like to have the control nonetheless.

Then I'd suggest Java may be ill-suited to your needs.

You may be able to get some level of GC control on a particular
JVM implementation, but it won't be robust. Your control is likely
to slip if you move your Java to another machine, or if you upgrade
the JVM, or even if you do something as innocuous as adjusting the
sizes of assorted memory pools.

For good or ill, Java's "attitude" about garbage collection is
that it's a service provided by the JVM -- in whatever way the JVM
sees fit to provide it, and the JVM is allowed to be capricious.

--
Eric Sosman
d

On 6/16/2012 11:24 AM, Eric Sosman wrote:
> Then I'd suggest Java may be ill-suited to your needs.


For us production coders, that's true. Depending on how experimental
Aaron's project is however, hacking the JVM may not be out of the
question. What he's talking about certainly sounds more academic to me,
so I'm sort of curious what methods he's going to use to achieve his goals.

On 6/16/12 12:24 PM, markspace wrote:
> On 6/16/2012 11:24 AM, Eric Sosman wrote:
>> Then I'd suggest Java may be ill-suited to your needs.
>
>
> For us production coders, that's true. Depending on how experimental
> Aaron's project is however, hacking the JVM may not be out of the
> question. What he's talking about certainly sounds more academic to me,
> so I'm sort of curious what methods he's going to use to achieve his goals.
It almost sounds like the Aaron may be better off using Event Loop style
architecture, with one event dispatch thread per CPU core. Allow the GC
to do what it does best, and have the operations be smaller and more
decoupled.

On 6/16/2012 4:14 PM, Daniel Pitts wrote:
> On 6/16/12 12:24 PM, markspace wrote:
>> On 6/16/2012 11:24 AM, Eric Sosman wrote:
>>> Then I'd suggest Java may be ill-suited to your needs.
>>
>>
>> For us production coders, that's true. Depending on how experimental
>> Aaron's project is however, hacking the JVM may not be out of the
>> question. What he's talking about certainly sounds more academic to me,
>> so I'm sort of curious what methods he's going to use to achieve his
>> goals.
> It almost sounds like the Aaron may be better off using Event Loop style
> architecture, with one event dispatch thread per CPU core. Allow the GC
> to do what it does best, and have the operations be smaller and more
> decoupled.

I, too, am mystified about what he's up to. It's hard to reconcile
an interest in tight control over GC with "Something that scales up
efficiently to distributed computing" -- the aims seem divergent.

Aaron: Care to share?

--
Eric Sosman
d

On 6/16/2012 1:14 PM, Daniel Pitts wrote:
> On 6/16/12 12:24 PM, markspace wrote:
>> On 6/16/2012 11:24 AM, Eric Sosman wrote:
>>> Then I'd suggest Java may be ill-suited to your needs.
>>
>>
>> For us production coders, that's true. Depending on how experimental
>> Aaron's project is however, hacking the JVM may not be out of the
>> question. What he's talking about certainly sounds more academic to me,
>> so I'm sort of curious what methods he's going to use to achieve his
>> goals.
> It almost sounds like the Aaron may be better off using Event Loop style
> architecture, with one event dispatch thread per CPU core. Allow the GC
> to do what it does best, and have the operations be smaller and more
> decoupled.
>


I dunno. Phase 1 of his little project might just be to implement a
regular old multi-threaded program in Java (probably one with some
specific characteristics that he's interested in).

Phase 2 might be to modify his local JVM and show that his special
GC/threading model produces some specific improvement(s), while running
the same byte codes as phase 1.

That's what I'd do, if I had the resources....

On Saturday, June 16, 2012 6:51:13 PM UTC+2, Aaron W. Hsu wrote:
> On Fri, 15 Jun 2012 21:37:32 -0400, Eric Sosman wrote:
>
> > Even if the thread you're interested in is careful not to create new
> > object instances, object creation in other threads can trigger the
> > garbage collector at pretty much any time.
>
> The garbage collector is one of the reasons that I have hesitated to move
> to Java. In some languages (Chez Scheme) I can get quite explicit
> control over when and how garbage collection occurs, which can make it
> possible to do very fine grained things to avoid some of the corner case
> problems that can manifest in garbage collected languages. Usually this
> is not a problem at all, but I would like to have the control nonetheless.

Be sure to try out G1 collector. In my brief tests so far it worked pretty well with regard to the target timings albeit at the expense of a bit of CPU overhead.

Kind regards

robert