From: Daniel M. <da...@im...> - 2005-04-01 19:43:16
|
I'm trying to develop a basic multi-threaded Windows application. In my current attempt, I call CreateThread in the WM_CREATE message handler. The message handler doesn't do anything else (for now), and the thread function draws some graphics onscreen. When I compiled using VC6 and /MT, this application runs fine. However, when I compile with mingw g++ 3.4.2, the program compiles without warnings, but when I run it, the main window appears but I don't see any output from the thread function. My thread function is: VOID Thread (PVOID pvoid) { // If I don't have the fprintf statement inside the // while loop, the function does not execute!! // unsigned loops = 0 ; // FILE *fd = fopen("\\dbg.txt", "wt") ; while (TRUE) { display_current_operation(hwnd); // fprintf(fd, "%u,", loops++) ; } // fclose(fd) ; } Interestingly, I found that if I include the file-printing operation which is currently commented out here, my graphics output *does* appear!! Again, this was not needed with the VC6 build. I'm assuming I need some switch that is equivalent to /MT under mingw?? How do I do this?? Or is the issue something else entirely?? |
From: Luke D. <cod...@ho...> - 2005-04-03 07:16:46
|
"-mthreads" is the equivalent switch, but I doubt it will make a difference because it really only affects C++ exception handling. Could you provide a small but complete example that demonstrates the problem? I think you also need to use _beginthread() instead of CreateThread(). Luke ----- Original Message ----- From: "Daniel Miller" <da...@im...> To: <min...@li...> Sent: Saturday, April 02, 2005 3:40 AM Subject: [Mingw-users] CreateThread quirk under mingw 3.4.2 > I'm trying to develop a basic multi-threaded Windows application. In my > current attempt, I call CreateThread in the WM_CREATE message handler. > The > message handler doesn't do anything else (for now), and the thread > function > draws some graphics onscreen. > > When I compiled using VC6 and /MT, this application runs fine. However, > when I compile with mingw g++ 3.4.2, the program compiles without > warnings, > but when I run it, the main window appears but I don't see any output from > the thread function. My thread function is: > > VOID Thread (PVOID pvoid) > { > // If I don't have the fprintf statement inside the > // while loop, the function does not execute!! > // unsigned loops = 0 ; > // FILE *fd = fopen("\\dbg.txt", "wt") ; > while (TRUE) { > display_current_operation(hwnd); > // fprintf(fd, "%u,", loops++) ; > } > // fclose(fd) ; > } > > Interestingly, I found that if I include the file-printing operation which > is currently commented out here, my graphics output *does* appear!! > Again, > this was not needed with the VC6 build. > > I'm assuming I need some switch that is equivalent to /MT under mingw?? > How do I do this?? Or is the issue something else entirely?? |
From: Earnie B. <ea...@us...> - 2005-04-03 10:08:20
|
<quote who="Luke Dunstan"> > > "-mthreads" is the equivalent switch, but I doubt it will make a > difference > because it really only affects C++ exception handling. Could you provide a > small but complete example that demonstrates the problem? > > I think you also need to use _beginthread() instead of CreateThread(). IIRC, MSDN gives warnings about mixing the C runtime thread API with the windows thread API so you need to use caution. Earnie > > Luke > > ----- Original Message ----- > From: "Daniel Miller" <da...@im...> > To: <min...@li...> > Sent: Saturday, April 02, 2005 3:40 AM > Subject: [Mingw-users] CreateThread quirk under mingw 3.4.2 > > >> I'm trying to develop a basic multi-threaded Windows application. In my >> current attempt, I call CreateThread in the WM_CREATE message handler. >> The >> message handler doesn't do anything else (for now), and the thread >> function >> draws some graphics onscreen. >> >> When I compiled using VC6 and /MT, this application runs fine. However, >> when I compile with mingw g++ 3.4.2, the program compiles without >> warnings, >> but when I run it, the main window appears but I don't see any output >> from >> the thread function. My thread function is: >> >> VOID Thread (PVOID pvoid) >> { >> // If I don't have the fprintf statement inside the >> // while loop, the function does not execute!! >> // unsigned loops = 0 ; >> // FILE *fd = fopen("\\dbg.txt", "wt") ; >> while (TRUE) { >> display_current_operation(hwnd); >> // fprintf(fd, "%u,", loops++) ; >> } >> // fclose(fd) ; >> } >> >> Interestingly, I found that if I include the file-printing operation >> which >> is currently commented out here, my graphics output *does* appear!! >> Again, >> this was not needed with the VC6 build. >> >> I'm assuming I need some switch that is equivalent to /MT under mingw?? >> How do I do this?? Or is the issue something else entirely?? > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435 Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435 SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Daniel M. <da...@im...> - 2005-04-05 20:28:46
|
"Luke Dunstan" <cod...@ho...> wrote in news:BAY...@ph...l: > > "-mthreads" is the equivalent switch, but I doubt it will make a > difference because it really only affects C++ exception handling. > Could you provide a small but complete example that demonstrates the > problem? > > I think you also need to use _beginthread() instead of CreateThread(). > > Luke > Okay, at the risk of posting too large of a message, I'm enclosing a stripped-down version of my program. It deletes all the graphics-drawing code, but includes everything else. I also switch to _beginthread() after reading the notes in msdn, but that has had no effect on program operation. Again, if I compile under VC6 with: cl /W3 /O2 /G4 /MT rainbowt.cpp user32.lib gdi32.lib this program works fine. If I compile under MinGW 3.4.2 with: g++ -Wall -s -O3 -mthreads rainbowt.cpp -o rainbowt.exe -lgdi32 the program runs, the main window is drawn, but no output ever appears. However, if I uncomment the file-printing debug code at the end of this code, then the g++ application runs just fine!!! Even eliminating the fprintf statement, however, puts me back to nothing drawing. I have *no* idea what fprintf has to do with any of this... I had included it just to find out whether or not my main thread was even being executed... Dan #include <windows.h> #include <stdlib.h> #include <math.h> #include <process.h> //*********************************************************************** LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ; int cxClient = 0 ; int cyClient = 0 ; static void display_current_operation(HWND hwnd); static VOID Thread (PVOID pvoid); HWND hwnd ; //*********************************************************************** int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { MSG msg ; WNDCLASSEX wndclass ; wndclass.cbSize = sizeof (wndclass) ; wndclass.style = CS_HREDRAW | CS_VREDRAW ; wndclass.lpfnWndProc = WndProc ; wndclass.cbClsExtra = 0 ; wndclass.cbWndExtra = 0 ; wndclass.hInstance = hInstance ; wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) ; wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) ; wndclass.hbrBackground = (HBRUSH) GetStockObject (BLACK_BRUSH) ; wndclass.lpszMenuName = NULL ; wndclass.lpszClassName = szAppName ; wndclass.hIconSm = LoadIcon (NULL, IDI_APPLICATION) ; RegisterClassEx (&wndclass) ; hwnd = CreateWindow (szAppName, szAppDesc, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL) ; ShowWindow (hwnd, iCmdShow) ; UpdateWindow (hwnd) ; while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg) ; DispatchMessage (&msg) ; } return msg.wParam ; } //*********************************************************************** LRESULT CALLBACK WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) { switch (iMsg) { case WM_CREATE: cxClient = 0 ; cyClient = 0 ; _beginthread(Thread, 0, NULL) ; return 0 ; case WM_SIZE: cxClient = LOWORD (lParam) ; cyClient = HIWORD (lParam) ; return 0 ; case WM_DESTROY: PostQuitMessage (0) ; return 0 ; } return DefWindowProc (hwnd, iMsg, wParam, lParam) ; } //***************************************************************** // this function plots one primary and one secondary pixel //***************************************************************** void display_current_operation(HWND hwnd) { if (cxClient == 0 || cyClient == 0) return ; //************************************* // draw graphics operation shere //************************************* } //***************************************************************** // separate thread for drawing function //***************************************************************** // #include <stdio.h> VOID Thread (PVOID pvoid) { // If I don't have the fprintf statement inside the // while loop, the function does not execute!! // unsigned loops = 0 ; // FILE *fd = fopen("\\dbg.txt", "wt") ; while (TRUE) { display_current_operation(hwnd); // fprintf(fd, "%u,", loops++) ; } // fclose(fd) ; } |
From: Luke D. <cod...@ho...> - 2005-04-06 12:09:46
|
----- Original Message ----- From: "Daniel Miller" <da...@im...> To: <min...@li...> Sent: Wednesday, April 06, 2005 4:24 AM Subject: [Mingw-users] Re: CreateThread quirk under mingw 3.4.2 > "Luke Dunstan" <cod...@ho...> wrote in > news:BAY...@ph...l: > >> >> "-mthreads" is the equivalent switch, but I doubt it will make a >> difference because it really only affects C++ exception handling. >> Could you provide a small but complete example that demonstrates the >> problem? >> >> I think you also need to use _beginthread() instead of CreateThread(). >> >> Luke >> > > Okay, at the risk of posting too large of a message, I'm enclosing a > stripped-down version of my program. It deletes all the graphics-drawing > code, but includes everything else. Your message is not too large. I was hoping that you could provide an example that compiles and runs, and visibly demonstrates the problem, but your example doesn't actually compile without changes so I assume you haven't tried running it either. By adding a small piece of drawing code to the thread, I can see that the thread runs normally and draws in the window (with no fprintf). This suggests that there is a bug in your program, and the fact that it works in MSVC may be accidental. Perhaps try posting again? Luke > > I also switch to _beginthread() after reading the notes in msdn, but that > has had no effect on program operation. Again, if I compile under VC6 > with: > > cl /W3 /O2 /G4 /MT rainbowt.cpp user32.lib gdi32.lib > > this program works fine. If I compile under MinGW 3.4.2 with: > > g++ -Wall -s -O3 -mthreads rainbowt.cpp -o rainbowt.exe -lgdi32 > > the program runs, the main window is drawn, but no output ever appears. > However, if I uncomment the file-printing debug code at the end of this > code, then the g++ application runs just fine!!! Even eliminating the > fprintf statement, however, puts me back to nothing drawing. I have *no* > idea what fprintf has to do with any of this... I had included it just > to find out whether or not my main thread was even being executed... > > Dan |
From: Daniel M. <da...@im...> - 2005-04-06 22:23:11
|
hmmm... okay, I'll post the whole thing, then. This compiles with the line shown at line 9. Dan //***************************************************************** // copy rainbow code from gstuff application // Try separate thread for the rainbow drawing function // // Written by: Daniel D. Miller // // Last Update: 03/10/03 11:34 // // compile with: g++ -Wall -O3 -s -mwindows -mthreads rainbowt.cpp // -o rainbowt.exe -lgdi32 //***************************************************************** // RAINBOWV.CPP: A rainbow simulator. // From "Astronomical Computing" // Sky & Telescope Magazine, February 1991 // Original program was in BASIC and EGA 4-color video mode. // // 05/27/98 // Converted to C and VGA/16-color by Dan Miller. // 08/09/02 16:11 // Converted into Win32 graphics program for more colors //***************************************************************** static char szAppName[] = "rainbow" ; static char szAppDesc[] = "draw simulated rainbow" ; #include <windows.h> #include <stdlib.h> #include <math.h> #include <process.h> // comment this line out to sleep on message queue // #define CONTINUOUS_REDRAW 1 // comment this line out to draw black window background // #define USE_SYS_BG_COLOR 1 //*********************************************************************** LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ; int cxClient = 0 ; int cyClient = 0 ; unsigned xbase, xdiff, ybase, ydiff ; static void display_current_operation(HWND hwnd); static VOID Thread (PVOID pvoid); HWND hwnd ; //*********************************************************************** int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { MSG msg ; WNDCLASSEX wndclass ; wndclass.cbSize = sizeof (wndclass) ; wndclass.style = CS_HREDRAW | CS_VREDRAW ; wndclass.lpfnWndProc = WndProc ; wndclass.cbClsExtra = 0 ; wndclass.cbWndExtra = 0 ; wndclass.hInstance = hInstance ; wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) ; wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) ; #ifdef USE_SYS_BG_COLOR wndclass.hbrBackground = (HBRUSH) (COLOR_WINDOW + 1) ; #else wndclass.hbrBackground = (HBRUSH) GetStockObject (BLACK_BRUSH) ; #endif wndclass.lpszMenuName = NULL ; wndclass.lpszClassName = szAppName ; wndclass.hIconSm = LoadIcon (NULL, IDI_APPLICATION) ; RegisterClassEx (&wndclass) ; hwnd = CreateWindow (szAppName, szAppDesc, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL) ; ShowWindow (hwnd, iCmdShow) ; UpdateWindow (hwnd) ; #ifdef CONTINUOUS_REDRAW // this loop repeatedly redraws the current screen, // any time there is no message on the queue. // It utilizes 100% of CPU time!! // If continuous redraw is not required, // use the GetMessage() loop below, instead. while (TRUE) { if (PeekMessage (&msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message == WM_QUIT) break ; TranslateMessage (&msg) ; DispatchMessage (&msg) ; } else { display_current_operation(hwnd) ; } } #else while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg) ; DispatchMessage (&msg) ; } #endif return msg.wParam ; } //*********************************************************************** HANDLE honkHandle; DWORD threadID; DWORD iterations; char msg[128] ; LRESULT CALLBACK WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) { // HDC hdc ; // PAINTSTRUCT ps; switch (iMsg) { case WM_CREATE: cxClient = 0 ; cyClient = 0 ; _beginthread(Thread, 0, NULL) ; // create a thread which // executes the "HonkThread" function // honkHandle = CreateThread(0, 0, // (LPTHREAD_START_ROUTINE) Thread, // (VOID *) iterations, 0, &threadID); // if (honkHandle == NULL) { // wsprintf(msg, "error=%u", GetLastError()) ; // MessageBox(hwnd, msg, "CreateThread", MB_OK) ; // } return 0 ; case WM_SIZE: cxClient = LOWORD (lParam) ; cyClient = HIWORD (lParam) ; xbase = cxClient / 2 ; xdiff = (cxClient-50) / 2 ; ybase = cyClient * 7 / 8 ; ydiff = cyClient * 5 / 8 ; return 0 ; // case WM_PAINT: // hdc = BeginPaint (hwnd, &ps) ; // display_current_operation(hwnd) ; // EndPaint (hwnd, &ps) ; // return 0 ; // case WM_KEYDOWN : // case WM_SYSKEYDOWN : // if (wParam == 27) // look for escape key // PostQuitMessage (0) ; // return 0 ; case WM_DESTROY: PostQuitMessage (0) ; return 0 ; } return DefWindowProc (hwnd, iMsg, wParam, lParam) ; } // ************************************************************************* * // generate random number between 0 and n-1 // ************************************************************************* * // In Numerical Recipes in C: The Art of Scientific Computing (William H. // Press, Brian P. Flannery, Saul A. Teukolsky, William T. Vetterling; // New York: Cambridge University Press, 1990 (1st ed, p. 207)), // the following comments are made: // // "If you want to generate a random integer between 1 and 10, // you should always do it by // // j=1+(int) (10.0*rand()/(RAND_MAX+1.0)); // // and never by anything resembling // // j=1+((int) (1000000.0*rand()) % 10); // // (which uses lower-order bits)." // ************************************************************************* * int random_int(int n) { // turn random number into a floating-point percentage double d = (double) rand() / (RAND_MAX + 1.0) ; // then calculate result as that random percentage of the target value return (int) (n * d) ; } // ************************************************************************* * // turn random number into a floating-point percentage // ************************************************************************* * double random_part(void) { return (double) rand() / (RAND_MAX + 1.0) ; } //***************************************************************** // RAINBOWV.CPP: A rainbow simulator. //***************************************************************** unsigned rainbow_index[6] = { 0x000000AA, // red RGB(255,165,0), // orange 0x0055FFFF, // yellow 0x0000AA00, // green 0x00AA0000, // blue 0x00AA00AA // violet } ; const double RADS2DEGS = (180.0 / 3.14159) ; double X, Y, B ; /************************************************************************ / void rainbow_plot_pixel(HDC hdc, int pcolor, double TH) { double f1 ; unsigned XP, YP ; TH = fabs(TH) ; if (TH > 60.0) return ; f1 = TH / 60.0 ; XP = (unsigned) (xbase + xdiff * (f1 * (X / B))) ; YP = (unsigned) (ybase - ydiff * (f1 * fabs(Y / B))) ; SetPixel(hdc, XP, YP, rainbow_index[pcolor]) ; } /************************************************************************ / // this function plots one primary and one secondary pixel /************************************************************************ / void display_current_operation(HWND hwnd) // void DrawRainbow(HWND hwnd) { HDC hdc ; int pcolor ; double N, I, R, T1, T2, RS, RP, RB, RC, I1, I2 ; if (cxClient == 0 || cyClient == 0) return ; // sprintf(tempstr, "cx=%u, cy=%u\n", cxClient, cyClient) ; // MessageBox(hwnd, tempstr, "status", MB_OK) ; // 30 REM RANDOM IMPACT PARAMETER X = -1.0 + 2 * random_part() ; Y = -1.0 + 2 * random_part() ; B = (double) sqrt(X * X + Y * Y) ; // square root // 50 IF B >= 1 THEN 30 if (B >= 1.0) { return ; } hdc = GetDC (hwnd) ; // select random color and calculate index of refraction pcolor = random_int(6) ; // select 1 thru 6 N = 1.33 + 0.01 * (double) (pcolor) ; // 70 REM COMPUTE ANGLES I = asin(B) ; // angle of incidence R = asin(B / N) ; // angle of refraction // calculate observation angles for // primary (T1) and secondary (T2) rainbows. T1 = (4 * R - 2 * I) * RADS2DEGS ; T2 = (6 * R - 2 * I) * RADS2DEGS - 180 ; // 95 REM INTENSITY FACTORS // RS = (sin(I - R) / sin(I + R)) ^ 2 ; RS = (double) (sin(I - R) / sin(I + R)) ; RS *= RS ; RP = (double) (tan(I - R) / tan(I + R)) ; RP *= RP ; RB = (1 - RP) * (1 - RP) ; RC = (1 - RS) * (1 - RS) ; I1 = ( RS * RC + RP + RB) / 2 ; I2 = (RS * RS * RC + RP * RP * RB) / 2 ; // Greenler's method: rather than computing intensities // for individual points, we randomly throw away some // computed points in the low-intensity regions. if (I1 >= .04 * random_part()) rainbow_plot_pixel(hdc, pcolor, T1) ; if (I2 >= .02 * random_part()) rainbow_plot_pixel(hdc, pcolor, T2) ; ReleaseDC (hwnd, hdc) ; } //***************************************************************** // separate thread for drawing function //***************************************************************** // #include <stdio.h> VOID Thread (PVOID pvoid) { // If I don't have the fprintf statement inside the // while loop, the function does not execute!! // unsigned loops = 0 ; // FILE *fd = fopen("\\dbg.txt", "wt") ; while (TRUE) { display_current_operation(hwnd); // fprintf(fd, "%u,", loops++) ; } // fclose(fd) ; } |
From: Luke D. <cod...@ho...> - 2005-04-07 01:50:08
Attachments:
rainbow2.png
|
It seems to work fine for me (attached part of a screenshot). I am using GCC 3.4.2 with the same command line options as you. What operating system are you using? Does it make a difference if you remove -O3? I don't know what else to tell you, but it doesn't seem to be a MinGW problem so far. Luke ----- Original Message ----- From: "Daniel Miller" <da...@im...> To: <min...@li...> Sent: Thursday, April 07, 2005 6:19 AM Subject: [Mingw-users] Re: CreateThread quirk under mingw 3.4.2 > hmmm... okay, I'll post the whole thing, then. This compiles with the > line shown at line 9. > > Dan > > //***************************************************************** > // copy rainbow code from gstuff application > // Try separate thread for the rainbow drawing function > // > // Written by: Daniel D. Miller > // > // Last Update: 03/10/03 11:34 > // > // compile with: g++ -Wall -O3 -s -mwindows -mthreads rainbowt.cpp > // -o rainbowt.exe -lgdi32 > //***************************************************************** |
From: Daniel M. <da...@im...> - 2005-04-07 19:29:27
|
"Luke Dunstan" <cod...@ho...> wrote in news:BAY...@ph...l: > > It seems to work fine for me (attached part of a screenshot). I am > using GCC 3.4.2 with the same command line options as you. What > operating system are you using? Does it make a difference if you > remove -O3? I don't know what else to tell you, but it doesn't seem to > be a MinGW problem so far. > Ok, first of all, I'm using Windows XP SP1. Now, I found that the program runs fine with -O1, or with no optimizations at all, but fails with -O2 or greater. Are you saying you used -O3 and it still worked?? What would make a difference between our machines?? Dan > Luke > > ----- Original Message ----- > From: "Daniel Miller" <da...@im...> > To: <min...@li...> > Sent: Thursday, April 07, 2005 6:19 AM > Subject: [Mingw-users] Re: CreateThread quirk under mingw 3.4.2 > > >> hmmm... okay, I'll post the whole thing, then. This compiles with >> the line shown at line 9. >> >> Dan >> >> //***************************************************************** >> // copy rainbow code from gstuff application >> // Try separate thread for the rainbow drawing function >> // >> // Written by: Daniel D. Miller >> // >> // Last Update: 03/10/03 11:34 >> // >> // compile with: g++ -Wall -O3 -s -mwindows -mthreads rainbowt.cpp >> // -o rainbowt.exe -lgdi32 >> //***************************************************************** > > Attachment decoded: untitled-2.txt > ------=_NextPart_000_0039_01C53B57.290564A0 > > Attachment decoded: rainbow2.png > ------=_NextPart_000_0039_01C53B57.290564A0-- |
From: Earnie B. <ea...@us...> - 2005-04-08 00:27:09
|
On 7:26:19 pm 2005-04-07 Daniel Miller <da...@im...> wrote: > "Luke Dunstan" <cod...@ho...> wrote in > news:BAY...@ph...l: > > > > > It seems to work fine for me (attached part of a screenshot). I am > > using GCC 3.4.2 with the same command line options as you. What > > operating system are you using? Does it make a difference if you > > remove -O3? I don't know what else to tell you, but it doesn't > > seem to be a MinGW problem so far. > > > Ok, first of all, I'm using Windows XP SP1. > > Now, I found that the program runs fine with -O1, or with no > optimizations at all, but fails with -O2 or greater. > > Are you saying you used -O3 and it still worked?? What would make a > difference between our machines?? > Binutils version? Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435 Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435 SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Luke D. <cod...@ho...> - 2005-04-08 02:13:42
|
----- Original Message ----- From: "Daniel Miller" <da...@im...> To: <min...@li...> Sent: Friday, April 08, 2005 3:26 AM Subject: [Mingw-users] Re: Re: CreateThread quirk under mingw 3.4.2 > "Luke Dunstan" <cod...@ho...> wrote in > news:BAY...@ph...l: > > > > > It seems to work fine for me (attached part of a screenshot). I am > > using GCC 3.4.2 with the same command line options as you. What > > operating system are you using? Does it make a difference if you > > remove -O3? I don't know what else to tell you, but it doesn't seem to > > be a MinGW problem so far. > > > Ok, first of all, I'm using Windows XP SP1. > > Now, I found that the program runs fine with -O1, or with no > optimizations at all, but fails with -O2 or greater. > > Are you saying you used -O3 and it still worked?? What would make a > difference between our machines?? > > Dan $ ld -v GNU ld version 2.15.90 20040222 I am using Windows 2000 on this PC, so that is one possibility (more likely than binutils I think). There is at least one race condition in your code, but I doubt it would cause these problems: the thread could check the condition (cxClient == 0 || cyClient == 0) after cyClient has been set but before xbase, etc. have been set. Perhaps you should try using GDB to debug the problem (after adding -g to the compile command of course)? It probably won't be easy when compiled with -O3 though because of the extensive inlining. Luke |
From: Daniel M. <da...@im...> - 2005-04-08 17:14:33
|
"Luke Dunstan" <cod...@ho...> wrote in news:BAY...@ph...l: > >> Are you saying you used -O3 and it still worked?? What would make a >> difference between our machines?? >> >> Dan > > $ ld -v > GNU ld version 2.15.90 20040222 > > I am using Windows 2000 on this PC, so that is one possibility (more > likely than binutils I think). > > There is at least one race condition in your code, but I doubt it > would cause these problems: the thread could check the condition > (cxClient == 0 || cyClient == 0) after cyClient has been set but > before xbase, etc. have been set. > > Perhaps you should try using GDB to debug the problem (after adding -g > to the compile command of course)? It probably won't be easy when > compiled with -O3 though because of the extensive inlining. > > Luke > Okay, I've got version GNU ld version 2.15.91 20040904 ... probably not enough difference to matter... I may change my cxClient test just to make sure that's not the issue, though I also doubt that it is in this case... Can I use gdb to debug a Windows program?? I'd always assumed that wouldn't work. I tried an earlier version of Insight, which didn't work with Windows apps... Dan |
From: Daniel M. <da...@im...> - 2005-04-08 17:36:47
|
Okay, I've gotten another insight into this issue. I tried running gdb against this utility, compiling it with -O3, and discovered that display_current_operation() is never executing at all!! I'm getting a suspicion that at the higher optimization levels, my while(1) loop is getting removed completely for some reason. As an experiment, I changed the base thread function as shown below, and it now runs even at -O3 !! Note that this is *still* a loop-forever loop, since the counter will never get beyond 20000 to reach the terminal count... Fortunately, the optimizer isn't smart enough to figure this out (though lint complained about it...). So, if my reasoning is correct, then either the optimizer is arbitrarily eliminating the while(1) statement, or it thinks that display_current_operation() can be optimized away completely. The latter is more likely, but why would it make such an assumption?? Dan "Luke Dunstan" <cod...@ho...> wrote in news:BAY...@ph...l: > > ----- Original Message ----- > From: "Daniel Miller" <da...@im...> > To: <min...@li...> > Sent: Friday, April 08, 2005 3:26 AM > Subject: [Mingw-users] Re: Re: CreateThread quirk under mingw 3.4.2 > > >> "Luke Dunstan" <cod...@ho...> wrote in >> news:BAY...@ph...l: >> >> > >> > It seems to work fine for me (attached part of a screenshot). I am >> > using GCC 3.4.2 with the same command line options as you. What >> > operating system are you using? Does it make a difference if you >> > remove -O3? I don't know what else to tell you, but it doesn't seem >> > to be a MinGW problem so far. >> > >> Ok, first of all, I'm using Windows XP SP1. >> >> Now, I found that the program runs fine with -O1, or with no >> optimizations at all, but fails with -O2 or greater. >> >> Are you saying you used -O3 and it still worked?? What would make a >> difference between our machines?? >> >> Dan > > $ ld -v > GNU ld version 2.15.90 20040222 > > I am using Windows 2000 on this PC, so that is one possibility (more > likely than binutils I think). > > There is at least one race condition in your code, but I doubt it > would cause these problems: the thread could check the condition > (cxClient == 0 || cyClient == 0) after cyClient has been set but > before xbase, etc. have been set. > > Perhaps you should try using GDB to debug the problem (after adding -g > to the compile command of course)? It probably won't be easy when > compiled with -O3 though because of the extensive inlining. > > Luke > |
From: Daniel M. <da...@im...> - 2005-04-08 17:44:30
|
Daniel Miller <da...@im...> wrote in news:Xns96326BB383CBBdancarddupercom@80.91.229.5: > Okay, I've gotten another insight into this issue. > I tried running gdb against this utility, compiling it with -O3, and > discovered that display_current_operation() is never executing at > all!! > > I'm getting a suspicion that at the higher optimization levels, > my while(1) loop is getting removed completely for some reason. As an > experiment, I changed the base thread function as shown below, and it > now runs even at -O3 !! Note that this is *still* a loop-forever > loop, since the counter will never get beyond 20000 to reach the > terminal count... Fortunately, the optimizer isn't smart enough to > figure this out (though lint complained about it...). > > So, if my reasoning is correct, then either the optimizer is > arbitrarily eliminating the while(1) statement, or it thinks that > display_current_operation() can be optimized away completely. The > latter is more likely, but why would it make such an assumption?? > > Dan > oops... forgot the code!! //***************************************************************** VOID Thread (PVOID pvoid) { unsigned j = 0 ; // while (TRUE) { while (j < 20000000U) { display_current_operation(hwnd); if (j < 20000) j++ ; } } > "Luke Dunstan" <cod...@ho...> wrote in > news:BAY...@ph...l: > >> >> ----- Original Message ----- >> From: "Daniel Miller" <da...@im...> >> To: <min...@li...> >> Sent: Friday, April 08, 2005 3:26 AM >> Subject: [Mingw-users] Re: Re: CreateThread quirk under mingw 3.4.2 >> >> >>> "Luke Dunstan" <cod...@ho...> wrote in >>> news:BAY...@ph...l: >>> >>> > >>> > It seems to work fine for me (attached part of a screenshot). I am >>> > using GCC 3.4.2 with the same command line options as you. What >>> > operating system are you using? Does it make a difference if you >>> > remove -O3? I don't know what else to tell you, but it doesn't >>> > seem to be a MinGW problem so far. >>> > >>> Ok, first of all, I'm using Windows XP SP1. >>> >>> Now, I found that the program runs fine with -O1, or with no >>> optimizations at all, but fails with -O2 or greater. >>> >>> Are you saying you used -O3 and it still worked?? What would make a >>> difference between our machines?? >>> >>> Dan >> >> $ ld -v >> GNU ld version 2.15.90 20040222 >> >> I am using Windows 2000 on this PC, so that is one possibility (more >> likely than binutils I think). >> >> There is at least one race condition in your code, but I doubt it >> would cause these problems: the thread could check the condition >> (cxClient == 0 || cyClient == 0) after cyClient has been set but >> before xbase, etc. have been set. >> >> Perhaps you should try using GDB to debug the problem (after adding >> -g to the compile command of course)? It probably won't be easy when >> compiled with -O3 though because of the extensive inlining. >> >> Luke >> > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. Discover which products truly live up to the hype. Start > reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Luke D. <cod...@ho...> - 2005-04-10 15:00:58
|
----- Original Message ----- From: "Daniel Miller" <da...@im...> To: <min...@li...> Sent: Saturday, April 09, 2005 1:32 AM Subject: [Mingw-users] Re: Re: Re: CreateThread quirk under mingw 3.4.2 > Okay, I've gotten another insight into this issue. > I tried running gdb against this utility, compiling it with -O3, and > discovered that display_current_operation() is never executing at all!! > > I'm getting a suspicion that at the higher optimization levels, > my while(1) loop is getting removed completely for some reason. Yes, but as I said GCC 3.4.2 works for me so I doubt that. If you want to be sure, compile your code (the infinite loop version) with -S instead of -c to generate an assembly language output file, and have a look at the Thread() function to see whether the loop and the call to display_current_operation() is actually there. Luke > As an > experiment, I changed the base thread function as shown below, and it now > runs even at -O3 !! Note that this is *still* a loop-forever loop, since > the counter will never get beyond 20000 to reach the terminal count... > Fortunately, the optimizer isn't smart enough to figure this out (though > lint complained about it...). > > So, if my reasoning is correct, then either the optimizer is arbitrarily > eliminating the while(1) statement, or it thinks that > display_current_operation() can be optimized away completely. The latter > is more likely, but why would it make such an assumption?? > > Dan > > "Luke Dunstan" <cod...@ho...> wrote in > news:BAY...@ph...l: > >> >> ----- Original Message ----- >> From: "Daniel Miller" <da...@im...> >> To: <min...@li...> >> Sent: Friday, April 08, 2005 3:26 AM >> Subject: [Mingw-users] Re: Re: CreateThread quirk under mingw 3.4.2 >> >> >>> "Luke Dunstan" <cod...@ho...> wrote in >>> news:BAY...@ph...l: >>> >>> > >>> > It seems to work fine for me (attached part of a screenshot). I am >>> > using GCC 3.4.2 with the same command line options as you. What >>> > operating system are you using? Does it make a difference if you >>> > remove -O3? I don't know what else to tell you, but it doesn't seem >>> > to be a MinGW problem so far. >>> > >>> Ok, first of all, I'm using Windows XP SP1. >>> >>> Now, I found that the program runs fine with -O1, or with no >>> optimizations at all, but fails with -O2 or greater. >>> >>> Are you saying you used -O3 and it still worked?? What would make a >>> difference between our machines?? >>> >>> Dan >> >> $ ld -v >> GNU ld version 2.15.90 20040222 >> >> I am using Windows 2000 on this PC, so that is one possibility (more >> likely than binutils I think). >> >> There is at least one race condition in your code, but I doubt it >> would cause these problems: the thread could check the condition >> (cxClient == 0 || cyClient == 0) after cyClient has been set but >> before xbase, etc. have been set. >> >> Perhaps you should try using GDB to debug the problem (after adding -g >> to the compile command of course)? It probably won't be easy when >> compiled with -O3 though because of the extensive inlining. >> >> Luke >> |