Re: Mutable Objects and Thread Boundaries

Alan Gutierrez wrote:


I don't want to sound snarky or anything, but I think piggy-backing with
side effects is still something to be very careful of.

Will everyone who comes after you be just as aware of BlockigQueue's
semantics? And will you remember yourself at 3 am while trying to make
some last minute code changes?

Other than the obvious (the object being enqueued itself) if you rely on
any side effects, I'd document the heck out of them. E.g.:

package test;
import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingDeque;

/* Threadsafe */
public class PiggyBack {

    private final BlockingQueue<String> queue =
            new LinkedBlockingDeque<String>();

    /* Guarded by queue */
    private int received;

    public int send( String s ) throws InterruptedException {
       int retVal;
       /* make atomic */
       synchronized( this ) {
          retVal = received += s.length();
       }

       /* received is guarded by this queue, not the synchronized
        * block above.
        * do not re-order the update to received below this line.
        */
       queue.put( s );

       return retVal;
    }

    public int getReceived() {
       /* must access queue to provide thread safety.
        * field "received" is guarded by the queue via piggy-backing.
        */
       queue.peek();
       return received;
    }

    public String recv() {
       return queue.poll();
    }
}

This may be a silly example, but that's the sort of thing I'm talking about.