Usually, your program is getting 99% of the CPU anyways, multithreading gives no noticeable speedup, and will probably give a slow down due to the additional context switching and synchronization overhead.

I tried this once, I created a multithreaded app with two CPU intensive threads. Doing the two intensive CPU calculations in parallel took 8.67 seconds. Doing it a sequentially in a single thread took 8.63 seconds.

If you're locking any of these surfaces, remember lock makes the system acquire the Win16Lock.

Also, please don't mess with SetPriority, you can cause major problems with your system by doing this (if you set it too high, disk buffers won't flush.)

I'm not saying never use multithreading, use it in the right situation. IO intensive tasks are great to put in another thread, since they spend most of their time blocked (waiting for a slow IO device like a disk) and if you're smart, you can get the effect of disk accesses taking zero time. User input in another thread is ok also (just please don't make it a busy-wait constantly checking the DInput states.)

Edited by - mhkrause on 2/22/00 8:11:59 AM

My game was taking up 99% of the cpu power, then i added 2 more threads and it only uses 76%. Maybe it''s not sped-up, but it can handle a lot more now without fear of slowing down. Multi-threaded applications are good, multi-threaded rendering may not be so good, what is going to guarantee that the background is the last thing to be drawn and the only thing to be seen? You might be able to do it, but it would involve more than just threads and end up being more trouble than it''s worth

Technically, the 386 had native support for multiple processes in a sort of 8086 multiple virtual machine setup. Yes, 8086, the granddaddy of them all. I''ve never seen this taken advantage of it, as the OS had run specifically in that mode, and essentially no OS runs in that funky mode, but it''s in the 386 technical specs.

However, I believe the original idea in the parallel mode point was that the 486 was pipelined, which is true. The second pipeline only handled about a third of the instruction set, and only ran the instructions it could handle about 1 in a 3 times, but it was there. The 586 was simply pipelined much much better.

But really all the discussion of pipelined/parallel whatever is essentially pointless because the CPU still only executes a single thread of execution at one time. It will *not* execute a different thread in each pipeline. Even under the superscalar cores. In order to truly benefit from multi-threading you need multiple processors. Multiple threads on a single processor machine just simplifies bookkeeping for the programmer (and trashes the cache). For something like rendering the overlap in computation between the threads combined with the threading overhead make multi-threading impractical.

If your UNIX system is running each thread as a separate process, then you have an old and/or non-POSIX compliant version of UNIX. POSIX provides for multiple threads of execution within a single process. And last I checked linux was POSIX compliant.

quote:
Is this an unwritten rule? Of course, i can code whole app in asm and nothing can stop me

Except maybe rising aspirin costs.

Just another idea for using threads in games: Would it be possible to use 2 threads in place of a triple buffer? One thread could handle the game logic and the other could handle rendering... Once the rendering thread finished, it could use a simple semaphore to tell the logic thread to start again, and then call flip() That way you could start the next game loop while waiting for your vsync.

Is this doable? I haven''t done any tests yet, but it seems like it has some potential.