Sign in to follow this  
Fuji

Threads and Auto-Save

Recommended Posts

I created a game a few days ago and recently learned about threads. The way I had the game before was to have it write to a file every time the button was clicked. Threads seem a lot more reasonable for this type of thing, and the clicking seemed to lag on some computers. Thus, I'm choosing for my semi-final design(because the all you can do is click a button. It HAS to be updated) to have the game save when the frame is closed and also to save each time the thread runs. This isn't working too well. The thread runs once as the program begins but then does not run again. Here's the code that controls the thread. Help me with any advice if possible: run = new MyRun(); thread = new Thread(run); thread.start(); class MyRun implements Runnable { public void run() { try { ObjectOutputStream os = new ObjectOutputStream(new FileOutputStream("playerdata.ser")); os.writeObject(player1); System.out.println("Saved"); } catch (IOException i) { i.printStackTrace(); } finally { // finally } try { Thread.sleep(60000); } catch(InterruptedException ie) { ie.printStackTrace(); } } }

Share this post


Link to post
Share on other sites
A Java thread does not loop. Once the run method is done, the thread will exit. If you want it to loop you have to do that yourself.


run() {
while(true) {
autosave();
sleep();
}
}



You're gonna have to make access to that player object synchronized if you're going down this route, otherwise you're gonna have some serious and hard to understand bugs.

Share this post


Link to post
Share on other sites
Yup. You are better off just using Async IO calls to save the file (sorry don't know what those would be in java). OR, making sure you write the save into a memory buffer. Then in a thread, actually write out that memory buffer to a file.

Share this post


Link to post
Share on other sites
Read this.

As a first guess I believe you will need a synchronized block around writeObject(), using player1 as lock, as well as making most if not all methods of your Player object synchrnized (depends on what you have in there). But be careful about liveness problems.

Share this post


Link to post
Share on other sites
The only methods in the Player class are setters and getters. The rest is all done in the main class. There's no reason to synchronize those or I'll take a performance hit.

Share this post


Link to post
Share on other sites
It's quite the opposite... if a setter is called while you are writing out the object, you are in trouble. If you want to share data between threads, you will have to take the performance hit from synchronization or come up with a different scheme (look into Java NIO or think about KulSeran's other idea - write the object to buffer in main thread, then save buffer to file in autosave thread. This way only access to this buffer needs to be synchronized. I think Java concurrency packages offer some high-level data structures for sharing data between threads, although I've not looked into it. Filesystem IO is very slow and is what will cause any stutters you notice, after all.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this