would it be possible to create a kind of 'stuff to serialize' queue, where you have a 'worker thread' that owns the queue (a vector of the objects you want serialized).. so your threads create a request 'token' that contains the reference to the thing you want serialized, and any additional information that is needed to do the work.
these tokens get queued up by the many threads trying to do the writing, and a single worker thread processes these tokens.
I created something like this one time, at band camp, to make a multi threaded
java application invoke a JNI COM bridge, which is horribly not thread safe.
consider,
where a possible use for this
So that should write stuff to the object output stream allowing multiple threads to submit things to be written.
clearly there is no way with this current sample to ensure what order things will get written out of course, many threads submitting things could cause some indeterminate order of things written out. I guess as long as the thing being written out is in itself not dependent on the order it was written out then that is ok.
Note the 'boxing' of the thing we want to write into a 'token' object container is useful to allow for storage of other things like statistics counters, timers, etc over time. I used a model like this for the reverse direction too, where a single data source (select rows from a database), would queue up and this worker would dispatch a token to more than one row processing child worker, because in that case each row was also independent on its order, but the dividing up the work through a simple vector queue is pretty effective.