Monday, 31 October 2011

Java Threads: Shared Java Queue 2: Queue Harder

Sorry, couldn't help myself with the title.

Anyway, just a short post today, and that's because our Synchronized Queue object basically already conforms to the Queue objects (or rather the interface). Its methods are monitored forwarding methods. That is, they deal with all the necessary object locking (synchronize), but that's it. Beyond that, they just call the methods of the actual Queue.
TL;DR: It's now up to actual Queues to be doing this right. We've already protected everything with our wrapper class.

Testing the queue is where the real annoyances start. To effectively do so, we'll need like....a producer/consumer system where there's multiple of each all working with the same 1 queue. The producers get to add values to the queue, the consumers get to take. This, in itself, is simple, but then again, multithreading is freakin' hard. At least from what I've seen so far. The text clock was among the easiest I can think of, and that doesn't count since it was only being used by itself :P
TL;DR: Test to learn how to use. Problem: It's hard. Solution: come up with a plan. Plan: Producer system adds to queue, consumers remove. Still hard, but now we have a foundation.

So I'll give you some time to think about how we'd implement this producer/consumer system, and tomorrow I'll show you the implementations I wrote, and then we'll be done with the shared queue! There'll still be an example or two to go, though. Even after writing this stuff I'm not sure I have what it takes to write a card game :P

Anyway, that's all for now, questions/comments welcome etc. See you tomorrow, etc.


  1. It was interesting.

  2. I have no idea what to do so I'm going to comment on your witty title instead. :P

    I need more witty titles...