Unix programming (processes, threads, semaphores..), any useful to game programming?
Author
Hi!
I'm studying unix programming in a class called Operating Systems. (i'm in computer engineer course)
And to be honest i'm not really motivated because it feels that it has nothing (or related) to do with game programming.
My question is: Do you think that this subject in the future might be useful in game programming?
thanks :)
Those topics are not Unix-specific at all, they are concepts that are universal to nearly every operating system or platform out there. As such, they are extremely useful in most application domains, including game development, especially since they are related to concurrency which is the direction in which you will likely see computing power scaling in the future.
The UNIX way of doing these things is really pretty straightforward. So, even if you're not going to do any actual UNIX programming in your future, it's a great platform to use to learn the basic concepts.
This:
fork();
is easier to use than this:
hThread = CreateThread( NULL, attributes,0, MyThread,pData, 0, &dwThreadId);
It's kind of like how we tell our little children to put differently-shaped blocks into holes. We aren't doing it to prepare them for a future career of putting blocks into holes, we're doing it because it teaches them the basic concepts of shapes.
This:
fork();
is easier to use than this:
hThread = CreateThread( NULL, attributes,0, MyThread,pData, 0, &dwThreadId);
It's kind of like how we tell our little children to put differently-shaped blocks into holes. We aren't doing it to prepare them for a future career of putting blocks into holes, we're doing it because it teaches them the basic concepts of shapes.
Get motivated. These are among the more useful topics. They relate to every aspect of high performance computing.
In addition, learning *nix architecture is probably more productive than Windows - at core, Windows looks like a toy, and has merely emulated some of the basic concepts.
The topics you will need from there in just about every aspect of programming are concurrency (scheduling, process management), memory management (protection, access, mapping to hardware) and IO (bottlenecks, different ways, trade offs).
In addition, *nix architecture is still the basis for many of today's APIs or at very least design choices in many of today's APIs - BSD sockets are just as frequently used as they were.
In addition, learning *nix architecture is probably more productive than Windows - at core, Windows looks like a toy, and has merely emulated some of the basic concepts.
The topics you will need from there in just about every aspect of programming are concurrency (scheduling, process management), memory management (protection, access, mapping to hardware) and IO (bottlenecks, different ways, trade offs).
In addition, *nix architecture is still the basis for many of today's APIs or at very least design choices in many of today's APIs - BSD sockets are just as frequently used as they were.
Quote:Original post by pinacolada
The UNIX way of doing these things is really pretty straightforward. So, even if you're not going to do any actual UNIX programming in your future, it's a great platform to use to learn the basic concepts.
This:
fork();
is easier to use than this:
hThread = CreateThread( NULL, attributes,0, MyThread,pData, 0, &dwThreadId);
It's kind of like how we tell our little children to put differently-shaped blocks into holes. We aren't doing it to prepare them for a future career of putting blocks into holes, we're doing it because it teaches them the basic concepts of shapes.
Generally I agree with what you say, except for your example.
fork() does have nothing to do with threads, it creates a child process. CreateThread and the POSIX's equivalent pthread_create(...) are quite similar just like other non-optional POSIX features. Also you can work on the POSIX subsystem on Windows, having the Windows' NT kernel fully POSIX.1 compliant.
And besides that, how exactly is that interface complicated, all you need is to provide the necessary arguments to get a thread started.
Maybe I misunderstood your intention of comparing fork to thread creation, in that case I am sorry for putting out something you probably already know.
Back to topic:
Whatever you learn about programming will help you with game programming. It's not only about learning concepts like multithreading or synchronization, which are actually in high demand in the gaming industry now, but also about how to solve problems using different approaches. You'll have to get used to your tools and find more efficient ways to solve bugs, which is not that trivial in a multithreaded environment.
You'll find out that the biggest difference in developing on Windows and on a Unix platform will be the tools you have at your disposal.
That is the only reason I prefer Windows when I have the choice.
Quote:Original post by kiome
Generally I agree with what you say, except for your example.
fork() does have nothing to do with threads, it creates a child process. CreateThread and the POSIX's equivalent pthread_create(...) are quite similar just like other non-optional POSIX features. Also you can work on the POSIX subsystem on Windows, having the Windows' NT kernel fully POSIX.1 compliant.
Yep, you are right. My Unix knowledge is very rusty (haven't touched it since college). Although I guess it is awfully hypocritical for me to tell some guy that he should learn the difference between a thread and a process, and then confuse them myself. :)
Quote:Original post by niner
And to be honest i'm not really motivated because it feels that it has nothing (or related) to do with game programming.
And being that you're still learning programming, perhaps you're not in a position to judge its relevance to game programming? [grin]
Pretty much anything you can learn about programming will be useful in *all* kinds of programming. Including game programming.
The worst thing you can do is cover your ears and ignore it if you can't immediately see the relevance.
If you're studying computer science or computer engineering, you kind of just have to trust that the people who put together that course knew better than you what you need to learn. [wink]
Remember in 3rd grade or whenever, when you asked your math teacher why you had to learn multiplication? Because when would *that* ever be useful in the real world? Or solving equations. Or whatever else. The problem with learning is that until you're past it, you can't really judge whether or not you're going to need it.
Quote:Original post by AntheusI'm surprised no one has called you out on this. Although there are some weird omissions, Windows supports everything just like any other OS. And let's be fair -- pthreads is pretty idiotic in places too.
In addition, learning *nix architecture is probably more productive than Windows - at core, Windows looks like a toy, and has merely emulated some of the basic concepts.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
