Re: Thread Safe Iostreams Patch

[David Sugar]

I think there are some target platforms that do have a threadsafe iostream.  
Is the SGI "stlport" also threadsafe?  If so, then maybe this should be 
something that could be enabled with a configure option.  This probably does 
belong in -head so people can experiment with it for a future release.

David

On Sunday 25 August 2002 19:59, Daniel E Baumann wrote:
> 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
>
>
> _______________________________________________
> Bug-commoncpp mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-commoncpp