Re: Thread Safe Iostreams Patch

[Daniel E Baumann]

On Sun, Aug 25, 2002 at 08:16:41PM +0200, Federico Montesino Pouzols wrote:
> 
> > Hello all. I have been hacking away at thread-safe iostreams and am
> > including a patch containing that work. At first I attempted to do
> > recursive locking but ran into some nice deadlock problems :(. So I
> > opted to lock the stream and buffer on operator<< calls and release at
> > the end of these calls. This does not give as nice output as I would
> > like and threads can get preempted between operator<< calls. Also,
> > there's a bunch of stuff that needs finishing. So baically this is just
> > a preliminary thing for you to look at, comment on, etc. If
> > anyone has a nice strategy on how to d recursive locking I am all
> > ears, else I will just have to give it more thought and figure
> > something out for myself.
> 
>       This looks very interesting, and it even comes with a test app
> :). I guess that now that we have a "stable" branch (RELEASE1) in CVS,
> this patch could be quickly added to HEAD so that people can start to
> play with it

Sure, that would be fine. I think the way I did the patch was kinda
goofy though and may not be the easiest to apply. I just left an
original tree in ~/tmp and had my modified one in ~/src/cvs/ and diffed
that from ~/. I really should move them into the same dir and rename one
so the patch can be applied easily with the proper -pX switch to
diff. Also, I have found some intersting design patterns here:

http://www.cs.wustl.edu/~schmidt/patterns-ace.html, and

here: http://www.cs.wustl.edu/~schmidt/PDF/locking-patterns.pdf

I know that we have the Scoped Locking pattern implemented in the
MutexLock class, but do you know of an Strategized Locking
implementations? Also I think I may be able to aviod the deadlock
issues if I follow the rules in the Thread-safe Decorator (Thread-safe
Interface) pattern. I think I was probably making intra-component calls
that did locking, which is a no no. They say you should write
"implementation" methods and only lock on the "interface methods" which
delegate to non-locking methods. At any rate, I think I'll try and
generalize the locking and write class(es) implenting these patterns.

Cheers,
Dan