Re: [Threading to manage simulated printing jobs]
Lew wrote:
Use logging, not System.out.println(). And isn't this the consumer?
getsanjay.sharma wrote:
I was told by someone not to use Javas' inbuilt logging API and rather
use 'log4j' and since this wa s a test program, I thought SOP's would
suffice the purpose.
Careless. System.out.println() is not for logging. The nice thing about
logging libs is that their overhead all but vanishes in production, so you
don't have to deploy code that's different from what you had in development.
Don't use System.out.println() for logging.
PrintJob job = queue.getJob();
Lew:
You'd better make sure the queue is synchronized!
getsanjay.sharma:
But I thought that since the PrintQueue methods are synchronized, I
don't need to do anything else, no?
All I said was to make sure the queue is synchronized. I didn't say it wasn't.
Individual method synchronization works as long as no single operation
requires more than one method call into the queue, as in your situation.
When you get this version working, think about using a blocking queue instead
of a non-blocking one. Your consumers will spin through CPU as you have
written things currently.
You might consider using one of the built-in Java queue classes, such as
java.util.concurrent.Class LinkedBlockingQueue<E>
Incidentally,
producer = new Producer(queue, "c:/" + i + ".txt");
displays the anti-pattern of hard-coded "magic" strings. Also, since you
apparently are running this on Windows, placing many files into the root
directory is kind of a Bad Idea.
--
Lew