It seems goroutine like process and channels are coming to C++: https://github.com/ahorn/cpp-channel

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 28 January 2014 at 17:25:35 UTC, Russel Winder wrote:
> It seems goroutine like process and channels are coming to C++:
> https://github.com/ahorn/cpp-channel

That's cool, but it is not going to be part of any standard? Is it?

O.

On Tuesday, 28 January 2014 at 17:25:35 UTC, Russel Winder wrote:
> It seems goroutine like process and channels are coming to C++:
> https://github.com/ahorn/cpp-channel


This is interesting, but you can bring that sort of approach to some other language as well. Here is a simple approach to get it done for Java: http://java.dzone.com/articles/go-style-goroutines-java-and. What is hard to implement without support from the language is the CSP-style channel select, which delivers a lot of the power of channels in Go.

Also, without green threads as in Go there is no way to spawn some hundred thousand threads as in Go. Java will start to get into its knees after some thousand threads already depending on how much resources are available to the machine. You can work around this by having a pool of threads process tasks added to queues where the number of queues can become very large. But when your thread pool has n threads and for an overlapping time window you have n long-runners being executed all other tasks are stuck till the first long runner has finished execution.

Green threads and CSP-style channels is what keeps a lot of people with Go as the rest of the language is almost simplistic. What I would really like to have is D with Go's green threads along with channels and channel select. Some people would now smile mildly, but for today's load on servers there is a real necessity. For example read this article "How We Went from 30 Servers to 2: Go". Link: http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2-go.html

Regards, Bienlein

On Tuesday, 4 February 2014 at 09:37:16 UTC, Bienlein wrote:
> This is interesting, but you can bring that sort of approach to some other language as well. Here is a simple approach to get it done for Java: http://java.dzone.com/articles/go-style-goroutines-java-and. What is hard to implement without support from the language is the CSP-style channel select, which delivers a lot of the power of channels in Go.

To follow up on this here is what Ian Taylor (member of Go dev team) says about this (in this thread: https://groups.google.com/forum/?hl=de#!topic/golang-nuts/kF_caFpPNgA):

I have not looked at your code.  I just want to say that the select
statement is the core of Go's channels.  Without select, channels are
just a simple communication mechanism.  If you want to design a
different implementation of Go's channels, I recommend designing
select first.

Support for green threads in std.concurrency is almost complete. I should really just do the last bit of work. I imagine you could try out the idea now though by using the messaging in vibe.d, since every connection is a fiber.

On 2/4/14, 10:05 AM, Sean Kelly wrote:
> Support for green threads in std.concurrency is almost complete. I
> should really just do the last bit of work. I imagine you could try out
> the idea now though by using the messaging in vibe.d, since every
> connection is a fiber.

Did you express that work as one or more bugzilla issues?

Andrei

On Tuesday, 4 February 2014 at 18:05:17 UTC, Sean Kelly wrote:
> Support for green threads in std.concurrency is almost complete. I should really just do the last bit of work. I imagine you could try out the idea now though by using the messaging in vibe.d, since every connection is a fiber.

Can you provide any more details? Right now vibe.d uses own implementation (https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d) - trying to replace with with updated Phobos one can be a good real-world test for such enhancement.

On Tuesday, 4 February 2014 at 19:19:22 UTC, Dicebot wrote:
> On Tuesday, 4 February 2014 at 18:05:17 UTC, Sean Kelly wrote:
>> Support for green threads in std.concurrency is almost complete. I should really just do the last bit of work. I imagine you could try out the idea now though by using the messaging in vibe.d, since every connection is a fiber.
>
> Can you provide any more details? Right now vibe.d uses own implementation (https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d) - trying to replace with with updated Phobos one can be a good real-world test for such enhancement.

My motivation was to make std.concurrency work with vibe.d.  And
more generally, to start testing fiber-based concurrency in
general.  The basic idea is to make certain low-level parts of
std.concurrency be pluggable, so the same API can be used on top
of different threading schemes.  You basically just need to
implement this interface:

interface Scheduler {
     void start(void delegate() op); // start the scheduler
     void spawn(void delegate() op); // spawn a new thread
     void yield(); // for send and receive to yield to allow green
threading
     Condition newCondition(Mutex m); // the condition will
notify/wait for new messages
}

I should have a sample implementation working for green threads
shortly.  Then I need to submit a bugzilla ticket and sort out a
pull request.

Okay, just for fun, here are some results with the new scheduler.
  I injected periodic yields into the code to simulate the
yielding that would happen automatically if the code was using
send and receive.  First the code:


shared long count = 0;

shared static ~this() {
	writefln("count = %s", count);
}

void childThread() {
	foreach(i; 0 .. 1_000) {
		atomicOp!"+="(count, 1);
		if (scheduler && 0 == i % 100)
			scheduler.yield();
	}
}

void mainThread() {
	foreach(i; 0 .. 100_000) {
		auto tid = spawn(&childThread);
	}
}

void runFibers() {
	scheduler = new FiberScheduler;

	scheduler.start(() {
		mainThread();
	});
}

void main(string[] args) {
	if (args.length > 1 && args[1] == "threads")
		mainThread();
	else if (args.length > 1 && args[1] == "fibers")
		runFibers();
	else writeln("specify threads or fibers");
}


And the results:


$ time concurrency threads
count = 100000000

real	1m11.033s
user	1m23.944s
sys	0m29.272s

$ time concurrency fibers
count = 100000000

real	0m5.998s
user	0m3.536s
sys	0m2.455s


I've got to say that I was surprised how fast 1 million kernel
threads were for this task.  That's orders of magnitude beyond
what I'd consider a sane number.

On Wednesday, 5 February 2014 at 01:02:37 UTC, Sean Kelly wrote:
> Okay, just for fun, here are some results with the new scheduler.
>   I injected periodic yields into the code to simulate the
> yielding that would happen automatically if the code was using
> send and receive.  First the code:

Hi Sean,

with "send and receive" you mean adding to a channel and doing a blocking take on it? Just for me to build up an understanding.

Regards, Bienlein