1

I am looking for patterns and api for managing with a Java object that is not thread safe, in the case that a parallel computation needs to use this object. This is applicable to database connections as well as other kinds of objects in my case (and in general).

The specific parallel scenario I am looking at is simply a Scala parallel collection that is being foreached, whereas within the foreach clause, the object needs to be used. Since the Java object at hand is mutable and not safe for concurrency, that is not supposed to work.

There is a nice suggestion here for that, in pure Java, and other ones also Java. I wonder if higher elegance can be accomplished in Scala.

Community
  • 1
  • 1
matanster
  • 15,072
  • 19
  • 88
  • 167
  • 1
    Wrap each instance in an actor. – Ryan Dec 01 '14 at 20:48
  • Is there some way to have actors pull work from a queue rather than be pushed work? pushing work calls for rebalancing techniques (see my other comment below) which are really not needed when workers pull from a queue... – matanster Dec 05 '14 at 19:26
  • 1
    Use the work pulling pattern. – Ryan Dec 05 '14 at 20:11
  • I don't see what the work pulling pattern wastes—it's essentially one extra actor (not even really—a router itself is an actor anyways). – Ryan Dec 06 '14 at 16:39
  • Yep you are right, here's by the way an implementation - https://github.com/mpollmeier/akka-patterns. My previous comment confused this with the BalancingPool router, sorry about that! – matanster Dec 08 '14 at 22:45

1 Answers1

2

I have faced this problem and solved this using Actors.

Each actor has access to the mutable object and it can only be modified using messages. In my case the mutable objects were heavy and have significant creation cost. In order to minimize that I created a bunch of them in the start and placed them behind an Akka router (smallestMailbox worked the best for my case). I've not seen a Future based approach to solve this problem yet.

Soumya Simanta
  • 11,523
  • 24
  • 106
  • 161
  • I may probably do this, but with a [balancing pool](http://doc.akka.io/api/akka/2.3.4/index.html#akka.routing.BalancingPool) as otherwise it may not squeeze out the most juice out of the available cores when the mailbox length is frequently 1. That is since in case I correctly understand, a message will be cleared from a routee actor's mailbox when the actor's `receive` method is called, not when it becomes available after finishing to process the message. hence work stealing/donation is needed as compensation, otherwise underutilization... my own suggestion admittedly feels too patchy... – matanster Dec 05 '14 at 19:18
  • I have implemented it with actors indeed, using a (balancing pool) router. It runs blazingly fast for my case, cpu utilization seems high enough when I stress the system around these objects. – matanster Dec 06 '14 at 15:46
  • But I'd recommend exploring [other existing solutions](http://stackoverflow.com/questions/8924086/how-to-create-an-object-pool-to-be-able-to-borrow-and-return-objects?rq=1) before delving into this type of solution. I find akka not optimal in approach and boilerplate, for merely serializing access to an object pool. I would prefer using simpler atomic execution facilities, a la [clojure atoms](http://clojure.org/atoms). Namely, just acquire an object and release it when done or failed, relying on atomicity for managing object state. Unless you made up your mind to use akka for everything.. – matanster Dec 06 '14 at 15:54
  • @matt - an object pool implementation will work. However, you still need to guard the access to objects from multiple threads, which may become a point of contention and thereby may have a negative impact on your performance. – Soumya Simanta Dec 06 '14 at 16:48