This site requires JavaScript, please enable it in your browser!
Greenfoot back
Twitter Twitter.hover

Comments for Multi Threading demo

Return to Multi Threading demo

tylerstylers

2012/5/7

please can you ive me the source
SPowerSPower

2012/5/7

If you want to learn, just follow the course. I'll post the source code, but not now.
martijn13039martijn13039

2012/5/7

nice pdf, it really help us a lot (maby next pdf how you can make a menu or something like that)
andrewsadikandrewsadik

2012/5/7

you have 2 objects that move even before you press "start"
SPowerSPower

2012/5/8

I know, that's the demo!!!!
martijn13039martijn13039

2012/5/8

adrewsadik please read the text and pdf and you see it is make for a demo
SPowerSPower

2012/5/8

@martijn13039 Maybe I will make a course about making a menu, but I first want to focus on school, and I first want to make a lesson about real object oriented programming (something most programmers don't do, unfortunately)
martijn13039martijn13039

2012/5/8

thats no big deal, it was only some advice (because not many people know how)
SPowerSPower

2012/5/8

Ok, but object oriented programming is more important (because Java is a object oriented language), and most people don't know how to do it right...
davmacdavmac

2012/5/8

SPower, there's nothing actually wrong with the material you've written (in fact it's nicely written) but: multi-threading is way, way harder than you might think. For simple examples, it's fine, but for anything more complex there are subtle issues that you need to be aware of. Although I can't see the source code for your scenario, I know it has a multi-threading bug: that is, it does something in a way that isn't thread-safe. Specifically, you shouldn't call Greenfoot API methods (particularly movement / collision checking) from another thread - because the Greenfoot API just isn't thread-safe. Now, it might [i]seem[/i] to work - but, if you run the scenario for a long time, or if you run it another computer, you might see an inexplicable failure which is due to internal data structures being corrupted, because they were accessed from two threads at the same time. Such problems are more common than you might think. In short, to save yourself from a world of pain with multi-threading, don't do it. If you want to see how complicated the code is to do correct multi-threading while using the Greenfoot API, you can have a look at one of my own scenarios: http://www.greenfoot.org/scenarios/1963
SPowerSPower

2012/5/8

Thanks for the feedback, davmac! I'll learn from your scenario.
A new version of this scenario was uploaded on Tue Jun 05 14:18:28 UTC 2012 Posted the source code as is: I didn't change it. And for the people who are interested: I'm working on a course about creating a menu
A new version of this scenario was uploaded on Tue Jun 05 14:20:32 UTC 2012 Removed useless code in 2 classes: forgot to do :)
tylerstylers

2012/6/14

it dont move unless you scroll the screen a bit then it stops.
Game/maniacGame/maniac

2013/9/9

Will having multiple threads increase the performance of a game with lots of actors?
SPowerSPower

2013/9/10

Well, your computer will still need to run those Actors' act methods, it just does it simultaniousl. So yes, it could help, but only if those act methods take a noticable time to run. Also, as davmac already pointed out, Greenfoot isn't thread safe: to do it completely safe you'll have to look at his scenario: http://www.greenfoot.org/scenarios/1963 So if you need the 'performance boost', I suggest you also check out his scenario and use it!