For ages, home computers had only one CPU/core and in those time almost all games only used one thread. They still ran well.
Even with a single thread you have more processing power at your hand on modern computers than all the game designers befeore had.
This one thread thing keeps getting repeated. Statistically very few games (since the 90s) have used one thread…other than embedded devices which would/will use an interrupt handlers to perform equivalent tasks. It very hard to get exact timings down other than on fixed hardware. The classic big issue here is input/output devices…notably keeping the sound output buffer filled. Using a language like java gives one a distorted view because you are multi-threaded…you’re just not explicitly creating more then one and the other threads are semi-hidden behind the scenes by the provided libraries.
@Roquen
I can’t really make sense of what you’re trying to say.
Looking at the OP’s post the most useful answer here is to use a single Thread.
I fully agree and said as much. But what I’m otherwise saying is let’s not propagate misinformation.
I didn’t intend to spread misinformation. And I’m fairly sure that until Windows games came up, there were almost no multi-threaded games.
An interrupt handler, although enabling quasi-concurrency in a program, is not a thread in my book. Maybe we just disagree on the terminology. Interrupt handlers were quite standard in the games.
The move from a non-OS (MS-DOS…was pretty much a binary loader) to a multi-process, preemptive multitasking OS is only part of the picture. DOS didn’t have threads, so there you go (actually you could with one of the various DOS-extenders)
The growing gap between CPU <-> FSB/Northbridge & Southbridge components is a biggy. One of the big early reasons for graphics cards to start adding computation functionality was to deal with pushing every increase amounts of data over a slow communication channel…the fact that you could do ever increasingly cool stuff was a bonus.
The bottom line is that modernish CPUs stall all the time: cache-miss? branch misprediction? data dependency? And these are just examples of short pauses.
Bottom line, given three machines all equal, except some hypothetical intel CPU:
A) 1 core @ 8.8Gz without HyperThreading
B) 4 cores @ 2.2Gz without HyperThreading
C) 4 cores @ 2.0Gz with HyperThreading
No question: I’d take C before B and B before A.
Threads, pico-threads/fibers/green-threads & interrupt handlers are all different, but fulfill a similar need…I didn’t intend to imply otherwise.
And that’s why I hate it when people measure computer speed by GHz and solely GHz…
To back this up: I benchmarked my own threaded ball physics test on an i7 860 quad core CPU at 3.52GHz, turbo disabled with hyperthreading.
1 thread: 110 FPS. 1x scaling
4 threads: 356 FPS. 3.24x scaling
8 threads: 478 FPS. 4.35x scaling
Each computer could be updated more quickly than other.
which is better, a Thread or a Timer to measure seconds and so make a good animation,stopwatch, etc…?
If you want accurate “wall-clock” (real) timing (ignoring any pausing mechanism) then simply do something like:
public static final long startTime = System.nanoTime();
Example:
public static final double getSecondsSinceLaunch()
{
return (System.nanoTime() - startTime) * (1.0/1.0e9);
}
EDIT: changed example from singles to doubles so I don’t have to bother with a precision discussion. 
GOLDEN THREAD RULE!
If you have to ask anything about them of anyone here… don’t use them.
Cas
sorry for the question, cas 
Actually, I appreciate the info you have given me, so I’ve seen the need to do all the game and see for myself that it is better, if a thread or 4.
It seems very convincing use only one thread but for the music it would have to use another?.
use two or more handle carries me to consider whether, for example, a single thread that manages counters and the other thread, repaints. The most important (repaints), could not possibly receive resources.
Anyway, I will prove, less overheating and work in an optimum way.
I hope you can help me again, if questions stupid arise like this.
thank you very much to all and approve what they said
The bottom line is to not worry about threads yet. Libraries will handle the basic required ones magically for you and you don’t need to think about them (much). But once you start to run into computational limitations of using only one thread, well you have somewhere else to go other than attempting to micro-optimize everything.