Erlang Actors and synchronized in Java.
So, I was being less than productive(well, not really...) and saw this: Actor's Guild, which is an Erlang style concurrency library for Java. Now, I've been writing a couple of application servers lately, so concurrency has been on my mind, and reading this has finally convinced that I am right. I already have such a framework, and the only thing I really need to "add" to it to make it a "Actor style" framework is just tell people to start using the synchronized keyword on their methods.
I realize that may sound insane, but I don't think it is. You see, the "core" of my app servers is in an implementation of this interface net.metanotion.util.observers.MessageBusManager. If you treat method = message, and instance = actor(which I do, by the way...), then just making your "messages" synchronized will do exactly the trick.
You see, the main implementation of MessageBusManager - net.metanotion.util.observers.ConcurrentMessageBusManager uses a thread pool to dispatch Message's, so each message sent will launch a tiny little Runnable into the thread pool, so absolutely nothing will block...
However, if you make methods on instances synchronized then even though messages to an object(actor) could be going through dozens of jobs in the thread pool, the synchronized keyword will create a "virtual"(or logical) thread out of the execution of the messages. Now, other than some ordering issues regarding the thread pool(which I am ignoring for simplicity's sake) this is exactly what an "actor" would look like. There's very little risk of deadlock here if you just apply the "formula"(part of the risk of developing in Java... yeah, yeah, I know), and despite the vilification of synchronized it will be unlikely to grind things to a halt here. Sure, there are resource issues with the the thread pool, but you can swap out what type you need, and besides, the actor model itself is no panacea, you can still create deadlocks and race conditions, its just harder and less pernicious, and a bit easier to reason about. And in the "FYI" category, there are various Java accelerators out there, they actually deal with synchronized blocks far better than we tend to assume.
And finally, if you're still worried about the scalability of my approach, I will remind you of my standard link on the issue: I'm Going To Scale My Foot Up Your Ass.
Oh yeah, I suspect I should still look at the Actor's Guild library I found, since I think they are using annotations to do what my IDL compiler does with regard to generating reified method calls(i.e. net.metanotion.util.Message objects).
I realize that may sound insane, but I don't think it is. You see, the "core" of my app servers is in an implementation of this interface net.metanotion.util.observers.MessageBusManager. If you treat method = message, and instance = actor(which I do, by the way...), then just making your "messages" synchronized will do exactly the trick.
You see, the main implementation of MessageBusManager - net.metanotion.util.observers.ConcurrentMessageBusManager uses a thread pool to dispatch Message's, so each message sent will launch a tiny little Runnable into the thread pool, so absolutely nothing will block...
However, if you make methods on instances synchronized then even though messages to an object(actor) could be going through dozens of jobs in the thread pool, the synchronized keyword will create a "virtual"(or logical) thread out of the execution of the messages. Now, other than some ordering issues regarding the thread pool(which I am ignoring for simplicity's sake) this is exactly what an "actor" would look like. There's very little risk of deadlock here if you just apply the "formula"(part of the risk of developing in Java... yeah, yeah, I know), and despite the vilification of synchronized it will be unlikely to grind things to a halt here. Sure, there are resource issues with the the thread pool, but you can swap out what type you need, and besides, the actor model itself is no panacea, you can still create deadlocks and race conditions, its just harder and less pernicious, and a bit easier to reason about. And in the "FYI" category, there are various Java accelerators out there, they actually deal with synchronized blocks far better than we tend to assume.
And finally, if you're still worried about the scalability of my approach, I will remind you of my standard link on the issue: I'm Going To Scale My Foot Up Your Ass.
Oh yeah, I suspect I should still look at the Actor's Guild library I found, since I think they are using annotations to do what my IDL compiler does with regard to generating reified method calls(i.e. net.metanotion.util.Message objects).