Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Valid_Dark]

I picked a language and assumed it was taught at a college somewhere, so I don't really know if it's offered, but I do know colleges offer story telling class, (my brother took it)

[alway]

The best analogy for the problems which arise in multithreading are the situations I've seen in OpenTransportTycoon. There's a reason multithreading functionality like mutexes and semaphores are named after railroad components. Race conditions resulting in collisions can be seen in quite literal terms, as can deadlocks, ect, resulting from semaphore problems and such.

[Mego]

Spoiler (click to show/hide)

Code: [Select]

#include <iostream>
#include <thread>

 
void helloworld() {
    std::cout << "Hello, World!" << std::endl;
}
 
int main() {

    std::thread t1(helloworld);
    t1.join();

    std::thread t2(helloworld);
    t2.join();

    std::thread t3(helloworld);
    t3.join();

    std::thread t4(helloworld);
    t4.join();
 
    return 0;
}

The problem is, most compilers don't have support for C++11 threads yet. So, for portable code at the moment, you have to do a clusterfuck like this:

Spoiler: Beware ye all who enter (click to show/hide)

Code: [Select]

#ifdef _WIN32
#include <windows.h>
class thread {
public:
LPSECURITY_ATTRIBUTES lpThreadAttributes;
SIZE_T dwStackSize;
LPTHREAD_START_ROUTINE lpStartAddress;
LPVOID lpParameter;
DWORD dwCreationFlags;
LPDWORD lpThreadId;
thread(LPSECURITY_ATTRIBUTES lpSec, SIZE_T stacksize, LPTHREAD_START_ROUTINE lpStart, LPVOID lpParam, DWORD flags, LPDWORD id) {
lpThreadAttributes = lpSec;
dwStackSize = stacksize;
lpStartAddress = lpStart;
lpParameter = lpParam;
dwCreationFlags = flags;
lpThreadId = id;
}
thread(LPTHREAD_START_ROUTINE lpStart, LPVOID lpParam, LPDWORD id = NULL) {
lpThreadAttributes = NULL;
dwStackSize = 0;
lpStartAddress = lpStart;
lpParameter = lpParam;
dwCreationFlags = 0;
lpThreadId = id;
}
HANDLE WINAPI run() {
return CreateThread(lpThreadAttributes, dwStackSize, lpStartAddress, lpParameter, dwCreationFlags, lpThreadId);
}
};
typedef DWORD WINAPI THREAD_TYPE;
#define DEFAULT_RETURN
#else
#include <pthread.h> // link with -lpthread
class thread {
public:
pthread_t* threadid;
const pthread_attr_t* attr;
void* (*start_routine)(void*);
void* arg;
thread(pthread_t* id, const pthread_attr_t* a, void* (*fn)(void*), void* param) {
threadid = id;
attr = a;
start_routine = fn;
arg = param;
}
thread(void* (*fn)(void*), void* param, pthread_t id = pthread_t()) {
threadid = id;
attr = NULL;
start_routine = fn;
arg = param;
}
int run() {
return pthread_create(threadid, attr, start_routine, arg);
}
};
typedef void* THREAD_TYPE;
#define DEFAULT_RETURN NULL
#endif


Even that isn't 100% portable, but it's closer.

[Valid_Dark]

I know
as I said before the compiler I use can't compile c++ yet either.
hopefully sometime this year most of the compilers will be up to date.

[MorleyDev]

Actually a good way around the C++11 support for threads I've found is to, if it's not supported, bring boost's threading classes into the std namespace.

I've got a whole set of headers I've been working on that exist solely around faking C++11 features that are missing in.

[malloc]

^ Threading gets hard when treading tasks that are not meant to be parallel, which is in fact, most of the stuff you will ever program.
What can be easily threaded are functions that are doing same task, perhaps with different parameters, a lot of times. They can share read only memory, but they should not share data that they manipulate, it introduces mutexes where data will be locked when a thread is using it.

If you have a large portion of a program which is more or less independent, for an example this could be a rasteriser or some smart query based pathfinding. If this component is more or less independent from the main program, that means it does not change or control any global states, you could thread it.

Some people often start foolishly threading everything, which is very error prone, and introducing some extremely complex series of mutexes you are essentially bogging your program down to a halt. You can even, by error, deadlock the program, because two threads are waiting for each other to finish.

Having dealt with threading a lot, I can honestly say that it will never be easy to thread applications. Also, few applications will actually get huge benefits from threading. If you are going to use threads, then only use them in places that you know are bottlenecks, and that can actually benefit from threading.

[MorleyDev]

Ah yes, designing for threading is....not fun. Especially making things scale to an unknown number of cores. Few things are embarrassingly parallel...

Building things as "Task-based" helps, and if something is functional it's very easy to run the parts that don't out-right depend on others in parallel.

Things like life-like Simulations are easy to make always use all of the available cores almost all of the time, you just split it into n sections and give each section to a thread. Process all sections, wait for all sections to be finished, repeat. You can keep it in synch with a barrier.

If most of the threads are spending most of their time waiting, then all you really have is a single-threaded program.

[Max White]

Let's face it, as with all things in computing, the more powerful, the harder it is.
Although that doesn't mean the harder it is, the more powerful, or brainfuck would be an industry standard language.

[MagmaMcFry]

Off-topic: When I was 13, I programmed a platformer with Perl/Tk. It was strictly procedural, had no kind of object structure, didn't use references or pointers, and on top of it all, used only global variables (not even function parameters). Input was raw terminal input, so the protagonist's speed depended on the system's keyboard settings (character repeat speed/delay), and every creature was drawn by changing the coordinates of 64 rectangles on Tk's canvas. Even so, it was completely playable, had checkpoints, power-ups, different types of badguys, moving platforms and even a final boss.

[Darvi]

There is something terribly inconsistent about Visual C++ trying to find and open files.

[Siquo]

"When I was 13", I made a game in qbasic, that had a 3D (first-person view, like you see in old RPG's) grid where me and my brother could walk around, and dig (splitscreen multiplayer). You were supposed to be an ant and shoot the other one with acid, or something.
In hindsight, I made a fucking Multiplayer-DF-FPS-crossover in qbasic.

So I just looked up the Qbasic site and, looking at the code there, I got this warm, fuzzy feeling. 

[Max White]

There is something terribly inconsistent about Visual C++ trying to find and open files.

You are meant to add files that you want to open to the project, and make them copy over on compile if newer.

[Darvi]

I did. 's just that my program manages to open one file, but not another which is located at the same place.

[Max White]

Sounds like some other IOException then. What sort of files?

[Stargrasper]

On the subject of Visual C++...I installed Visual Studio 11 Dev Preview solely because I could.  How the crap do I get VC++ to link libraries correctly?  For the life of me, I could not find the right linker operation...which is stupid considering how easy it is from the command line...  I historically do C++ development from Linux...I can handle a commandline so much better than an IDE, for the most part.