multi threading with dev-c++
KaBlammyman

I’m looking for any flags or options to specify to Dev-c++ (mingw32) to use multi threading. I have been trying to use functions such as:

HANDLE CreateThread(LPSECURITY_ATTRIBUTES secAttr,
                             SIZE_T stackSize,
                             LPTHREAD_START_ROUTINE threadFunc,
                             LPVOID param,
                             DWORD flags,
                             LPDWORD threadID);

or

  unsigned __stdcall threadfunc(void * param);

uintptr_t _beginthreadex(void *secAttr, unsigned stackSize,
                                   unsigned (__stdcall *threadFunc)(void *),
                                   void *param, unsigned flags,
                                   unsigned *threadID);

I am in need of multi threading programming for a Tetris game that uses a special custom device that sends data to the serial port. Since I have to read data from a serial port for input, the reading must be as fast as possible. So far, reading the serial port with a timeout (non-multi threading) slows my game to a crawl (Tetris run at 3fps!)

The code I use to attempt multi-threading will compile and what not, but I no longer get any data from the serial port…so something is wrong. It that I’m doing something wrong, or there are flags to be set with mingw32 just like in visual c++.

Also, any additional input (besides all the googling and msdn searching I did)on how to use the _beginthreadex() function would be nice.

Anyway, I hope I was clear on what I need help with…if not, let me know so I can clarify.

Thanx

orz

I haven't used multithreading w/ mingw32, and I haven't done any serial port programming recently enough to remember it, but this is my understanding:

You should be able to use CreateThread() without any special flags, though if linking with a non-multithreaded libc then of course libc calls won't be threadsafe. Though, I thought that mingw32 linked with a threadsafe libc by default.

Threading shouldn't be necessary for your problem, I think. Polling the serial port in a non-blocking fashion (ie without a timeout) should return near-instantly if no data is buffered, fast enough for you to poll it once per game tick without consuming noticable amounts of time. Timeouts when reading from normal input devices should not be used in realtime games. What interface are you using to talk to the serial port?

nonnus29

Lets see... After my adventure threading with win32 awhile back I read that windows interprocess communications (pipes) only provide a small buffer space and they have to be read constantly or you'll miss the output (or something). Have you looked into using pthreads on win32? I haven't tried it myself.

KaBlammyman
Quote:

haven't used multithreading w/ mingw32, and I haven't done any serial port programming recently enough to remember it, but this is my understanding:

You should be able to use CreateThread() without any special flags, though if linking with a non-multithreaded libc then of course libc calls won't be threadsafe. Though, I thought that mingw32 linked with a threadsafe libc by default.

Threading shouldn't be necessary for your problem, I think. Polling the serial port in a non-blocking fashion (ie without a timeout) should return near-instantly if no data is buffered, fast enough for you to poll it once per game tick without consuming noticable amounts of time. Timeouts when reading from normal input devices should not be used in realtime games. What interface are you using to talk to the serial port?

So, you are saying that I can leave out this part:

1// instance an object of COMMTIMEOUTS.
2 COMMTIMEOUTS comTimeOut;
3 // Specify time-out between charactor for receiving.
4 comTimeOut.ReadIntervalTimeout = 3;
5 // Specify value that is multiplied
6 // by the requested number of bytes to be read.
7 comTimeOut.ReadTotalTimeoutMultiplier = 3;
8 // Specify value is added to the product of the
9 // ReadTotalTimeoutMultiplier member
10 comTimeOut.ReadTotalTimeoutConstant = 2;
11 // Specify value that is multiplied
12 // by the requested number of bytes to be sent.
13 comTimeOut.WriteTotalTimeoutMultiplier = 3;
14 // Specify value is added to the product of the
15 // WriteTotalTimeoutMultiplier member
16 comTimeOut.WriteTotalTimeoutConstant = 2;
17 // set the time-out parameter into device control.
18 SetCommTimeouts(handlePort_,&comTimeOut);
19 // Updata port's status.

I tried setting everything to 0, but that does not help...in fact, it causes the program to not respond unless I change COMMTIMEOUTS comTimeOut; to COMMTIMEOUTS comTimeOut={0}; Then I dnt get any info from the seral port :(

The only thing I'm using to access the serial port are windows functions like "CreateFile" and GetCommState() with some of some the supplied structures. If you know how to truly turn off the timeout stuff...that would be great! I only tried to use multi threading to help speed things up a bit and because the old (and only) MSDN article on serial programming says to do that...but I couldn’t get that code to work with Dev-C++ :-[

Quote:

Lets see... After my adventure threading with win32 awhile back I read that windows interprocess communications (pipes) only provide a small buffer space and they have to be read constantly or you'll miss the output (or something). Have you looked into using pthreads on win32? I haven't tried it myself.

never heard of it. :D I'll google it.

EDIT:

I should add the code that reads from the serial port:

1bool read_scc( char* inputData,
2 const unsigned int& sizeBuffer,
3 unsigned long& length)
4{
5 if (ReadFile(handlePort_, // handle of file to read
6 inputData, // handle of file to read
7 sizeBuffer, // number of bytes to read
8 &length, // pointer to number of bytes read
9 NULL) == 0) // pointer to structure for data
10 {
11 printf("Reading of serial communication has problem.");
12 return false;
13 }
14 if (length > 0)
15 {
16 inputData[length] = '\0';//NULL; // Assign end flag of message.
17 //inputData[length] = NULL; // Assign end flag of message.
18 return true;
19 }
20 return true;
21}

maybe the way things are being read is not the best way.???

Double edit:
I downloaded pthread-win32, and built it. I keep getting linker errors no matter what tyoe of program i try (link with dll or static lib)
I get these errors:

Quote:

[Linker error] undefined reference to `_imp__pthread_exit'
[Linker error] undefined reference to `_imp__pthread_create'
[Linker error] undefined reference to `_imp__pthread_exit'
ld returned 1 exit status
*** [pThreadTest.exe] Error 1

orz

Hadn't looked at that API before. Bleh. Anyway, I think the way I'm recommending for typical game IO (non-blocking synchronous polling) would be like this:

comTimeOut.ReadIntervalTimeout = MAXDWORD;
comTimeOut.ReadTotalTimeoutMultiplier = 0;
comTimeOut.ReadTotalTimeoutConstant = 0;
</code>
According to this section of the MSDN docs for COMMTIMEOUTS, describing ReadIntervalTimeout:
A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received.

KaBlammyman

Thanx orz, that code did the trick!!!!:D8-)

Thread #588248. Printed from Allegro.cc