Just a quick question. For the flyweight idea in the article you get additional thread unsafeness even for immutable data in that you are changing where the flyweight points (which is how you want to do it to avoid creating and destroying a lot of flyweight objects). What is your idea to pool/control multiple flyweight accessors?

[Not sure whether the question is directed to the author or to my comment but I'll answer anyway :) ]

Basically, there are 3 notions

1) the buffer (byte[] or whatever) containing the data, immutable at least while the data is being accessed by a given thread

2) the Struct object: defines the structure of a message (field length, offset, arrays etc.)

3) the Message (aka the flyweight) that points to a given offset in buffer and is bound to a Struct instance

The buffer and the message are normally accessed by only one thread, but several threads can share Struct instances (i.e. the dictionary).

Each field (even deep in the field hierarchy) knows its offset relative to the beginning of the message, so values can be accessed like eg.

  int foo = struct.foo.getInt(msg);

The only complicated thing is when dealing with arrays (especially when nested in other arrays). The message does the bookkeeping necessary to safely access elements, ie. the mutable state is stored in the flyweight.

I like to have only one writer thread for any data. This can have its own flyweight. Other threads can be readers each having their own read only flyweight implementation.