Thoughts on OpenMP
I am looking at OpenMP and it seems to me that while it is about time they added standardized multithreading capability to the language, that OpenMP is probably not the best solution. I may be biased of course, since I already know how to do everything OpenMP does by using exant Windows procedures. I do see it as having some use in converting existing code over to run faster on multicore systems or for programmers that don't 'get' threads, I do not think it would be the best choice for all/new applications. Another benefit of course would be portability. If it is added to the standard, then theoretically parallel code written for Win32 should also compile for linux.
I know some pretty heavy number crunching companies use OpenMP, so I guess it can't be "horrible".
Like all multithreading, you need to get fairly large independent chunks of data to calculate in each thread - then the overhead of the mechanisms to present the work becomes less of an issue. If you have small chunks of work, no form of multithreading is really that efficient.
There's nothing wrong with it. It can pretty convenient. You could split a for loop into X threads very easily. I've only used it once, though, so I can't exactly say I'm an expert.
So look forward to someone else's advice too.
It's very terse. Compare the code overhead for making a computation loop multi-threaded with OpenMP - one line, I think, perhaps two or three - with the overhead from doing it by hand - something on the order of a dozen lines or two, if you consider the final joining. And that doesn't consider that the OpenMP implementation probably has a thread pool for the computation, and a message dispatching mechanism to use it. If you have to implement this yourself, it will be a lot more than just two dozen lines.
The job object API probably is a good alternative - I wouldn't be surprised if MS's OpenMP implementation used it internally.