aspose file tools*
The moose likes Beginning Java and the fly likes Synchronizing threads (multiple maze solving algorithms) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Synchronizing threads (multiple maze solving algorithms)" Watch "Synchronizing threads (multiple maze solving algorithms)" New topic
Author

Synchronizing threads (multiple maze solving algorithms)

Matt Hoover
Greenhorn

Joined: May 01, 2011
Posts: 21
For a school project, I am making a maze generating GUI, and also several different "solving mice" based on various solving algorithms. Each mouse gets its own thread. I know a very small amount about thread management in C/C++ (semaphores, mutexes, etc), but these solutions are all geared toward protecting shared access to variables, which isn't exactly what I'm looking for here (though it may be part of it).

What I want is to guarantee that no mouse moves faster than the other. No mouse is allowed to make his second move until every other mouse has completed his first move. What is a good way to implement this?

I came up with each mouse having a "step counter," and making each mouse's move conditional based on every other mouse's step count being caught up with his. This seems like it would work, I just want to make sure I'm not reinventing the wheel and there isn't an easier way to do it built in to Java.

Thanks!
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4467
    
    8

Sounds to me that the easiest approach would be not to give each mouse its own thread. Instead, use a Timer, and within each Timer event have each mouse move one step.
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

Unless you have a very good reason that you need to use threads, you should avoid them like the plague.
Matt Hoover
Greenhorn

Joined: May 01, 2011
Posts: 21
Luigi Plinge wrote:Unless you have a very good reason that you need to use threads, you should avoid them like the plague.

Why is that?

The last place I used them was in a Game of Life GUI where I had one thread that ran the "run continuously" method (for evolving between generations) while the main thread stayed open for key/mouse input. There, it seemed totally necessary.

Here, I will admit it might not be necessary. In fact, I created one thread in my MazeGUI class that constantly repaints the main frame, since the things that are happening in the actual base maze class (building a maze, solving the maze, etc, with time delays thrown in) don't have access to the repaint method in the MazeGUI class. Is this a bad approach?
Matt Hoover
Greenhorn

Joined: May 01, 2011
Posts: 21
Matthew Brown wrote:Sounds to me that the easiest approach would be not to give each mouse its own thread. Instead, use a Timer, and within each Timer event have each mouse move one step.

I may look into that, I hadn't heard of the Timer concept but it sounds nice.
Luigi Plinge
Ranch Hand

Joined: Jan 06, 2011
Posts: 441

Matt Hoover wrote:
Why is that?

They introduce complication into your code that makes it harder to program and much harder to debug. They introduce whole new classes of bugs, such as potential deadlocks, and to get round this you have to make code blocks synchronized. As a result, performance on a multi-threaded app is often worse than on a single-threaded one.

As CPUs become more multi-core, the need for multi-threading will increase, but I would hope that this would be done "under the covers", as it has been in Scala's parallel collections, or through language virtualization.

Here, I will admit it might not be necessary. In fact, I created one thread in my MazeGUI class that constantly repaints the main frame, since the things that are happening in the actual base maze class (building a maze, solving the maze, etc, with time delays thrown in) don't have access to the repaint method in the MazeGUI class. Is this a bad approach?

How are you doing that if you didn't know about Timer?

For some purposes, re-drawing the display according to a regular schedule specified by a Timer might be the best approach, but I'd have thought you'd be better off refactoring so that you can call repaint only after all your updates are done.
Matt Hoover
Greenhorn

Joined: May 01, 2011
Posts: 21
Luigi Plinge wrote:
How are you doing that if you didn't know about Timer?

In between every step of maze generation or solving, there is a Thread.sleep(x).

The repaint thread repaints constantly so the effect is that the maze building and solving is an animation with the speed of animation based on "x" above. I'm still guessing this is a bad idea since thread scheduler could technically give repaint thread control forever, and nothing else would ever progress? But so far it seems to be working. Of course I have quad-core computer, so maybe on single core this wouldn't work so well?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Synchronizing threads (multiple maze solving algorithms)