Re: streams and threads... why?
From: Matt Humphrey (matth_at_ivizNOSPAM.com)
Date: 01/29/04
- Next message: hiwa: "Re: please help, am i missing something simple?"
- Previous message: Tony Morris: "Re: some questions"
- In reply to: Steve Horsley: "Re: streams and threads... why?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 28 Jan 2004 20:23:00 -0500
"Steve Horsley" <shoot@the.moon> wrote in message
news:bv9bu3$gjb$1@news.freedom2surf.net...
> Frank wrote:
> > I acknowledge that in general, thread safety is a very important issue
> > when designing a module, but I'm curious how often do people really
> > concern themselves with thread safety regarding stream input?
> >
> > This question comes to mind particularly with regard to java.io.Reader.
> > While I don't concern myself with multithreaded reads, I'm writing this
> > message because I can't even fathom why anyone would?
> >
> > It seems (logical) to me that one would generally have a thread that
> > took your stream to read in fully descriptive "packets", then selected a
> > thread to delegate the packet to. Or perhaps, in the case of files,
> > allow concurrent InputStreams per each thread, even when they go to the
> > same file. Neither of which require locking of the stream itself.
> > Perhaps one could write a stream that encapsulated java.util.Random...
> > but that's not exactly a stream :) But incorporating locking semantics
> > so that multiple threads can compete to read from the same stream....
> > Why??? Has anyone actually done this?
> >
> > Cheers,
> >
> > Frank
>
> I would expect the whole java.io API to be thread-safe. Otherwise the
> whole think would be crash-prone if used by multiple threads, and teh
> failure of the API to perform as documented would clearly be a bug in
> the API. I can't think of a reason to read a stream with multiple
> threads either, but you have to write the API safely anyway.
I agree that if the API requirements state that some methods be thread-safe
(or synchronized) it would be a bug if they were not. However, I think the
question is really about the API requirements themselves. It would be nice
if all APIs were thread-safe, but some are not for good reasons. Rather,
APIs like Swing and some others (HashMap, TreeMap, etc) are not thread-safe,
but give you some techniques for making your program thread-safe. It's up
to the designer / developer to properly structure safety at a higher level.
The OP posed an interesting question: given that the Reader class includes a
deliberate locking mechanism, what are some real cases where multiple
threads read from the same stream? I havn't thought of any myself, but it's
also not clear to me that any Reader subclasses are necessarily thread-safe
either as it's up to the Reader implementation to use the locking object on
the critical sections itself (as indicated by the API docs). I would think
that if the documentation does not explicitly state that a class is
thread-safe, it is not (although it should really say one way or the other.)
How much of java.io really is thread-safe?
Cheers,
Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/
- Next message: hiwa: "Re: please help, am i missing something simple?"
- Previous message: Tony Morris: "Re: some questions"
- In reply to: Steve Horsley: "Re: streams and threads... why?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
