Boolean flags vs. multi-threading?

[TLE]

I'm programming basically a login screen for the launch of a game.  Is it better to set it up so everything uses boolean flags, like isLoggedIn, and just set up the graphics based on those, or is it more effecient to use multiple threads?

[Markus_Persson]

I'm programming basically a login screen for the launch of a game.  Is it better to set it up so everything uses boolean flags, like isLoggedIn, and just set up the graphics based on those, or is it more effecient to use multiple threads?

Yes. Don't use threads unless you know exactly why you're doing it. Code complexity goes up exponentially when you need to support multiple threads.

[Mr_Light]

code complexity only goes up when you don't know what your doing.

Games published by our own members! Check 'em out!

[oNyx]

http://en.wikipedia.org/wiki/Complexity

More lines of code (or more control flow statements or more possible states) increase the complexity.

I'm really sorry, but that's a fact.

[noblemaster]

@Everyone besides TLE: What's wrong with you guys   

http://en.wikipedia.org/wiki/Complexity
More lines of code (or more control flow statements or more possible states) increase the complexity.
I'm really sorry, but that's a fact.

That has nothing to do with the question! Also, the Wikipedia link does not state anything you mentioned.

code complexity only goes up when you don't know what your doing.

That's very helpful to know.

Yes. Don't use threads unless you know exactly why you're doing it. Code complexity goes up exponentially when you need to support multiple threads.

I agree with the first part. Although there are situations where multiple threads allow to make things easier to understand ...


@TLE: I am not so clear on your question, but I believe what you are looking for is a state pattern.
http://www.informit.com/articles/article.asp?p=28677&rl=1

You would build your game so you have a base State class. Then you implement:
LoginState extends State  -> allows to login and eventually proceed to the GameExecutionState
GameExecutionState extends State -> your actual game rendering loop is in this state.

Your game will be in one state at a given time, where it can proceed to other states. E.g. when the game starts, you could go through the following states:
TitleState -> "mouse click" -> LoginState -> "correct login" -> GameSelectionState -> "game selected" -> GameExecutionState ...
                                                                          -> "wrong login" -> LoginState ...

That way, you only need a single Thread ...

[Mr_Light]

code complexity only goes up when you don't know what your doing.
That's very helpful to know.

thanks i gues 

actually my motivation in posting that is all in your reply.

@TLE: I am not so clear on your question

so I decided to poke anound as perhaps it was just me, in any case I disagree the motivation of the
answer given. Yes most of the time the option is dismissed for good reasons.

Don't use threads unless you know exactly why you're doing it.

actually I'd go  with 'Don't use any unless you know exactly why you're doing it.' being a good practice.

to cut this offtopic stuff sort,
don't avoid multi threading because it's.. scary. this just obscures the engineering process.

Wenn using complexity to be more complex you need a point of reference.. Reguarding software metrics,
I can give examples of cases where cyclomatic complexity is equal or less that of the non-threaded variant.
Classifying something as 'complex', or rather to complex is subjective even more so wenn mixing in the
fact that transformation likely shifts the points of complexity around having various effects on the perspective.

ok thats not really cutting it short,

Although there are situations where multiple threads allow to make things easier to understand ...

although by the sound of it the state pattern suggestion is a good choice it only replaces the flagging bit with something more OO and has little influence on the multithreaded case the state switching or the boolean assigning.

[oNyx]

>That has nothing to do with the question!

Amazing! (The question was already answered.)

>Also, the Wikipedia link does not state anything you mentioned.

"Complexity is the opposite of simplicity." (at the very beginning)

[TLE]

Thanks for all the replies guys, lots of good info in there for me!

I like the state change ideas, I hadn't thought of that before but I saw it in another post.  I've written quite a bit just using loads of booleans, but the single class is getting a little big and harder to edit.  Plus, it seems like the overhead of checking booleans over and over that only need to be checked during log in for instance will get to be a problem -- eventually.  So I'll definitely be re-writing a lot of it into multiple states.

[Markus_Persson]

code complexity only goes up when you don't know what your doing.

This is simply not true.

[Mr_Light]

indulge me then, keep in mind I was replying to your reply.

Games published by our own members! Check 'em out!

[TLE]

He just meant that when you use multiple threads, the complexity goes up because there's more stuff going on, so it's more complex.  He didn't say it's hard to understand, just that it's more complex.  And it is, the more complicated you write something, the more complex it is.  And you've got the right idea too, Light, if you don't know what you're doing (*cough*me*cough*), the complexity makes it loads harder. 

[Markus_Persson]

indulge me then, keep in mind I was replying to your reply.

Show me an example of a multi-threaded solution of something that doesn't need to be, where the multithreaded solution is less or equally as complex as the singlethreaded one, and I will either point out a bug, or take a back my comment. =)

[Mr_Light]

whould someone who knows what there doing apply stuff where it doesn't need to be applied?

need is awefully ambious
without a formal description of complexy, it's subjective.

[ryanm]

Perhaps we can all agree that bugs arising from threading are far, far harder to replicate?

This alone is enough to keep me away from multithreading except in the cases of blocking I/O and GUIs.
I'm with Markus here, avoid multithreading unless your know exactly what you're doing and are absolutely sure of the benefits.

[TLE]

I can't believe you guys are arguing about the defintion of "complexity".

Here's dictionary.com's definition of complexity:
com·plex·i·ty     /kəmˈplɛksɪti/ – the state or quality of being complex;

And that's a real smartass definition, here's complex:
com·plex     /adj., v. kəmˈplɛks, ˈkɒmplɛks; n. ˈkɒmplɛks/  – composed of many interconnected parts; compound; composite: a complex highway system. 

[Kova]

lol this is a funny thread
But I strongly agree, in general multithreading is way more complex then other solutions. I also would like to know if there is an example where multithreading is better then singlethreaded solution (except NIO), as there aren't many or none at all.

[noblemaster]

e.g. a chat panel which communicates with a server. the chat panel would have a seperate thread so IO operations do not interfer/block the rest of the game.

[Mr_Light]

Perhaps we can all agree that bugs arising from threading are far, far harder to replicate?

This alone is enough to keep me away from multithreading except in the cases of blocking I/O and GUIs.
I'm with Markus here, avoid multithreading unless your know exactly what you're doing and are absolutely sure of the benefits.

could that be because there's no adequate tooling for it?

is this a self-sustaining thing?
Is it getting complex because we have poor understanding of it making the whole multi threaded area and thereby creating some kind of blackbox.

as soon as your directly or indirectly concerning yourself with time slicing (mechanisms), are where the cases are found. At other times it's not because of the increase of complexity but the side effect it brings, such as poor scaling.

we're not that far apart as to when to apply, it's much more the mindset round them that I disagree with I don't think ppl learning how to program should stay away from threads having an understanding about them allows they to make better decisions on when to avoid them.

I toss the example thing in a whole differend direction, say your system is composed out of 2 components component 1 is relatively small compared to component 2 component 1 claims 80% of the resources the other 20% there is a performance component 1 can be optimised by threads.. with some increasing in ~complexity a little for that component. or one could decorate component 2 with (sticking to single threaded) performance tricks increasing the ~complexity by a lot.

horray overall ~complexity was decreesed by going with the multithreaded approach.

[biggeruniverse]

This entire forum thread is multiple sub-threads within the main thread, which I think is undue given the definition of the problem.

Anyway, never use a simple dictionary, always get the etymology of a word: http://www.etymonline.com/index.php?term=complex

I like the 1715 version.

[ryanm]

could that be because there's no adequate tooling for it?

It's because thread scheduling is pretty much non-deterministic - it depends on OS, processor, system load, CPU temperature, user actions, phase of the moon, inside leg measurement, etc, etc. Being able to replicate a non-trivial bug is the only way to fix it, so deterministic behaviour is mighty useful.

By all means people should learn about multithreading -it's a useful technique and completely necessary for blocking I/O, responsive GUIs and parallelisable tasks on multi-core CPUs -  but if this learning process doesn't leave them with a deep-seated terror of debugging a multithreaded application then they haven't learnt enough. IMO anyway.

I'm probably misreading your example of why multithreading can make things simpler and/or more performant, but what you seem to be saying is "A system that can be optimised with multithreading can be optimised with multithreading". That's obviously true, but I can't think of a concrete example outside of <brokenrecord>blocking I/O, responsive GUIs, parallelisable tasks on multi-core CPUs</brokenrecord>.