Condition variables

Printable View

03-18-2008
sethjackson

Condition variables

I was trying to use condition variables on Windows, but I get a compiler error.
I believe that it is because my compiler (MinGW) doesn't have the definitions yet, but I'm not sure.

Anyways has anyone used condition variables on Windows Vista and gotten it to work with MinGW? I don't think I can just add the definitions in my headers can I? Because the linker won't be able to find the symbols in kernel32.lib right? Probably doesn't exist in the kernel32.dll either.....

BTW docs on condition variables are here for those interested. ;)
03-18-2008
abachler

Any reason to use the over say CriticalSection's, or semaphores?
03-19-2008
matsp

The symbols should be in the kernel32.lib and kernel32.dll.

You will need the correct definition in the header-file. I think all you actually need is a Windows SDK with the relevant "windows.h" [and it's sub-includes].

--
Mats
03-19-2008
Elysia

You can put the declarations in the header, but you shouldn't. Include the proper header (windows.h) and link with the correct library, and there you have it.
It should be included in the latest SDK.
03-19-2008
Codeplug

Unfortunately, I don't think that MinGW "works" with the platform sdk, due to ms-compiler specific extensions.

The win32api for MinGW can be downloaded here:
http://sourceforge.net/project/showf...ease_id=564368

But the source is maintained over at cygwin here:
http://cygwin.com/cgi-bin/cvsweb.cgi...y=date#dirlist

I don't see support condition variables, but you could support them yourself. First you'll have need to download the latest Platform SDK so you can get the proper definitions for CONDITION_VARIABLE.
Web Install
DVD ISO
Hopefully, someone who already has this will post the definition :)

Then you can define all the condition variable api's as global function pointers, and set them using GetProcAddress().

Another alternative is to switch to a microsoft compiler and use the latest platform sdk directly.

gg
03-19-2008
abachler

mingw has its own version of the sdk available as a package.

Then again, with VS 2005 being free to hobyists why not use that?
03-19-2008
sethjackson

Quote:

Originally Posted by abachler

Any reason to use the over say CriticalSection's, or semaphores?

Yes. Critical sections (Mutexes) aren't condition variables, neither are semaphores....

The problem with using condition vars on Windows for now is that they are Windows 6 (Vista/Server 2008) only.
I believe that Boost implemented condition vars with mutexes, and semaphores on the Windows platform since pre-Windows 6 kernels don't have condition vars.
Which I probably will have to do, but I would like to see if I can get the "native" ones to work.

Quote:

Originally Posted by Codeplug

Unfortunately, I don't think that MinGW "works" with the platform sdk, due to ms-compiler specific extensions.

Hmm I'm using the SDK that comes with MinGW.
But I never thought of using the MS SDK with MinGW.
I guess I could try that. Heh.

Quote:

Originally Posted by Codeplug

Another alternative is to switch to a microsoft compiler and use the latest platform sdk directly.

Quote:

Originally Posted by abachler

Then again, with VS 2005 being free to hobyists why not use that?

VS 2008 is free too. ;)

I've tried using the MS compiler, but I had too many issues with it
Building DLL's is a pain (you must do non-portable things), plus it doesn't support standard language keywords that I need (and, or, etc.). Otherwise I would use it.....
03-19-2008
Codeplug

>> But I never thought of using the MS SDK with MinGW. I guess I could try that.
It won't work with MinGW. Having the MS SDK on hand is good for extracting any definitions that aren't in the MinGW Win32API headers.

gg
03-19-2008
laserlight

Quote:

plus it doesn't support standard language keywords that I need (and, or, etc.).

Interesting observation. According to the C++ Standard, those keywords should be available and thus not defined as macro names in <ciso646>, but a little experimentation with VS 2005 shows that if you #include <ciso646>, those keywords will work.
03-19-2008
Elysia

Quote:

Originally Posted by sethjackson

Building DLL's is a pain (you must do non-portable things),

Huh? How so? I've been building DLLs for a long and it's a snap due to Visual Studio.

Quote:

...plus it doesn't support standard language keywords that I need (and, or, etc.). Otherwise I would use it.....

I can't believe anyone is using those... What's wrong with && and ||?
03-19-2008
laserlight

Quote:

I can't believe anyone is using those... What's wrong with && and ||?

Apparently, some characters like & and | are not easily typed on certain keyboards.
03-19-2008
matsp

Quote:

Originally Posted by laserlight

Apparently, some characters like & and | are not easily typed on certain keyboards.

Like Swedish one where you use Alt-GR 7..0 to give some of those - and I'm sure there are languages/countries where those are worse. Not to mention scandinavian [for example] 7-bit ASCII [yes, I know, it's again something OLD] which makes all the

Code:

|, {}, [] and \

into letters ä, å, ö and their uppercase variations [not necessarily in respective order].

--
Mats
03-19-2008
Elysia

Quote:

Originally Posted by matsp

Like Swedish one where you use Alt-GR 7..0 to give some of those...

That's not necessarily bad, though. It's absolutely fine.
03-19-2008
sethjackson

Quote:

Originally Posted by Elysia

Huh? How so? I've been building DLLs for a long and it's a snap due to Visual Studio.

I need import libs. You have to write __declspec(dllexport) before everything you want
to export. Yuck, and unnecessary with MinGW (GCC).

Quote:

Originally Posted by Elysia

I can't believe anyone is using those... What's wrong with && and ||?

Well there is at least one person on earth using those, me. :)
See above posts for more reasons.
03-19-2008
Elysia

Quote:

Originally Posted by sethjackson

I need import libs.

Need import libs? I don't think I understood that one.

Quote:

Originally Posted by sethjackson

You have to write __declspec(dllexport) before everything you want to export. Yuck, and unnecessary with MinGW (GCC).

That or use a .def file. That's standard way. And it isn't "yuck." It's a very handy way to actually export functions and classes and variables.
03-19-2008
sethjackson

Quote:

Originally Posted by Codeplug

>> But I never thought of using the MS SDK with MinGW. I guess I could try that.
It won't work with MinGW. Having the MS SDK on hand is good for extracting any definitions that aren't in the MinGW Win32API headers.

gg

Ok.

Quote:

Originally Posted by laserlight

Interesting observation. According to the C++ Standard, those keywords should be available and thus not defined as macro names in <ciso646>, but a little experimentation with VS 2005 shows that if you #include <ciso646>, those keywords will work.

Yeah but that is wrong. Like you said in C++ they aren't macros, they are keywords.

Thanks everyone. :)
03-19-2008
Elysia

Quote:

Originally Posted by sethjackson

Yeah but that is wrong. Like you said in C++ they aren't macros, they are keywords.

I'm going to agree that it's bad. If it's in the standard, they should exist. Bad Microsoft.
I'm actually with you on this one :)