5 ms·
I've always really, really liked Ada's rendezvous-based concurrency. There's more to it than I can really describe here, but in effect it allows you to treat a
by david-given 11y ago
I've always really, really liked Ada's rendezvous-based concurrency.
There's more to it than I can really describe here, but in effect it allows you to treat a thread as an object with methods; calling a method on the object sends a message to the thread. The thread's main code can, at any point, block and wait for a message, or combination of messages.
The handling code looks like this:
...some code...
accept DoSomething(value: in out integer) do
...some code here...
end
...some more code...
That causes the thread to block and wait for the message. When the message is sent, the caller blocks, the receiver runs the handler, then the caller resumes.
The beauty here is that inside the message handler, you know that the caller is blocked... which means it's safe to pass parameters by pointer[]. Everywhere the parameter's in scope, the parameter is safe to use. The type system won't let the thread store the pointer anywhere without copying the contents first, so you get zero-copy messaging and* it's failsafe.
You can also do really cool stuff with timeouts, guards, automatic thread termination, etc. Here's a simple multithreaded queue (syntax and logic not guaranteed, it's been a while):
loop
select
when usage < capacity =>
accept Push(value: in integer) do
data[usage] := value;
usage := usage + 1;
end;
or
when usage > 0 =>
accept Pop(value: out integer) do
usage := usage - 1;
value := data[usage];
end;
or
terminate;
end select;
end loop;
Multithreaded! Blocks the client automatically if they pop while the queue's empty or push while it's full! Automatically terminates the thread when the last connection goes away and the thread leaves scope! Thread safe! Readable!
I'd love to be able to do this in a more mainstream language.
[*] This is a simplification. Ada's pointers are not like other language's pointers.
- msbarnett 11y agoThe older I get, the clearer it is that Ada was the answer to the last 2 decades worth of problems (fast, able to go low-level when you need to, very type safe, easy concurrency primitives) and we all just ignored it because it wasn't fashionable.
- bliti 11y agoYou and me both. I day dream about working on Ada. end of random quibble
- david-given 11y agoI would love to have a modernised Ada. With case sensitivity. And garbage collection (a lot of the language semantics are obviously intended to be based around having a garbage collector. I'm very surprised that it never seemed to get one). And a less wacky OO system (invisible syntax, ugh). But those are quibbles, and at it's heart it's still an excellent, excellent language. And there are Ada compilers in Debian, it's still being maintained, it compiles really quickly into excellent code, it interoperates beautifully with C...
- com2kid 11y ago> And a less wacky OO system (invisible syntax, ugh). Didn't Ada 2005 fix the OO system to give it the CLASS syntax everyone is used to? Ada's usual syntax and declaring class inheritance are isomorphic with each other, the transformation a compilers does are the same, but non-JS programmers are used to class inheritance syntax. I've always wondered if JS programmers would actually pick up on Ada's object system faster, just because they wouldn't mind the lack of an explicit inherits quite so much. As for GC, I thought it was optional in Ada, just never implemented. For most of Ada's target audience though, heap allocators are already verboten, so GC isn't needed. :) I'd really like some of Rust's ownership semantics along with Ada's already well developed feature set. Pointer ownership is still a gnarly problem, I don't recall what, if anything, Ada does to help out with it.
- msbarnett 11y agoI don't mind the lack of GC. Storage pools are reminiscent of Objective-C's autorelease pools, which I've always thought were a very nice way of handling a group of objects' lifetimes. > And a less wacky OO system (invisible syntax, ugh). Not sure what you mean by this one? > And there are Ada compilers in Debian, it's still being maintained, it compiles really quickly into excellent code, it interoperates beautifully with C... I came across http://www.getadanow.com http://www.getadanow.com the other day. Really easy way to get Ada going on OS X, too.
- IanCal 11y agoIf I've understood this correctly, this sounds very much like erlangs concurrency. Elixr I guess by extension too. Old, tatty code but: https://github.com/IanCal/semq/blob/master/src/messagequeue.erl https://github.com/IanCal/semq/blob/master/src/messagequeue.... This made message queues that would pause if there was a pop on an empty queue (for long-polling), supports removing everything and if a new 'client' connects while another is waiting for an item sends an error message to the original client. I'm sure there's a neater way of doing it but this sat and ran for quite a while for me and didn't take long to write :) Generally, the loops are achieved by making an infinitely recursive function call, and you can therefore switch between major behaviours by having multiple functions. For a quick syntax thing, sending a message is "address ! message" and what I think the "accept" in your code is equivalent to a 'receive' in mine. You won't have the same type safety, but the general pattern of just blocking and waiting safely is there. It's a fun language, and people seem to be pretty happy with elixr these days too (built on top). There's some better examples here: http://learnyousomeerlang.com/the-hitchhikers-guide-to-concurrency http://learnyousomeerlang.com/the-hitchhikers-guide-to-concu... http://learnyousomeerlang.com/more-on-multiprocessing http://learnyousomeerlang.com/more-on-multiprocessing
- Matthias247 11y agoIt's a little bit different. In Ada it's a real rendezvous. Either the "client" or the "server" task is running. In Erlang the mailbox is asynchronous, which means the server can't make any assumptions about what state the client is in while it works on processing the message and sending it back and the client can't assume that the server is directly working on the message after it put it in his mailbox.
- majewsky 11y agoIf I read the snippet correctly, that's a stack, not a queue.
- david-given 11y agoAh, you spotted my deliberate mistake! Er, yes. It's a stack. Oops. Ta.