multi-threaded application in C++

[dimm_coder]

Originally posted by _uj
The ability to link external libraries is NOT enougth. The libraries that come with the compiler must be guaranteed threadsafe, otherwise there's no way a program can become multithreading no matter what other stuff you link to it. But today I'd say all major compilers have threadsafe vesions of their standard libraries. The important thing is to make sure you use them.

Yes, of course. Someone, developing a threaded application, have to use threadsafe versions of libraries, otherwise he is seeking for problems on his head. But I have meant a "pure" compiler without any environmant libraries.
gcc goes without any libraries. It's just a compiler. In addition, there is a set of libraries available for writing applications. That set of libraries, needed for application, depends on goals and design of program. e.g. for FreeBSD someone can use libc for non-threaded program and libc-r for multithreaded.

[Sam Hobbs]

Note that it was the statement "the Microsoft compilers do not have support for posix" that resulted in many replies. So the question is not all compilers, the question is whether the Microsoft compiler can support Posix. Even if we were talking about all compilers, the point would still be whether the compiler must provide direct support of Posix. Whether a specific compiler is capable of generating programs that use Posix is not relevant to the point that if a compiled program is capable of using Posix, it can be generated by a compiler that was not provided (installed) with direct support of Posix.

[abc_coder]

Originally posted by Sam Hobbs
Note that it was the statement "the Microsoft compilers do not have support for posix" that resulted in many replies. So the question is not all compilers, the question is whether the Microsoft compiler can support Posix. Even if we were talking about all compilers, the point would still be whether the compiler must provide direct support of Posix. Whether a specific compiler is capable of generating programs that use Posix is not relevant to the point that if a compiled program is capable of using Posix, it can be generated by a compiler that was not provided (installed) with direct support of Posix.

you're adding to the confusion here.

[list=1][*] for certain platforms, where there's no underlying OS support for threading (dude_1967 mentioned microcontrollers - an easier example could have been running DOS on your post-386 processor), the compiler has to provide threading support in the runtime (no, the compiler is NOT just a compiler - it has to come with runtime libraries at least - for dimm-coder, compile hello_world and do a ldd on the executable; chances are that you'll have a dynamic one linked to libgcc_s.so.*).
[*] if the OS has support for threading (in Sam's case, Windows dows) and the OS-dependant libraries provide threading interfaces (again, Windows' do), then for Posix compliance you need a wrapper library to convert the Posix calls to the OS-specific calls for the threading (read pthread) interface - that is, if the OS's interface is not Posix-compliant already. The degree of compliance depends on the OS's threading support (for instance, vanilla Linux 2.4.* is less compliant than 2.6.* due to different threading support in the kernel).
[*] On the next level comes threading support in your ('regular') libraries - meaning whether they're thread-safe or not (only after you can create threads, you start worrying about multithreaded access to your program's objects). so you get stuff like -mt or _r libraries in parallel to the regular ones.
[/list=1]

Finally, to answer Sam (if still needed), google for "pthreads win32" and you'll find a Posix threads library that you can compile and use with MSVC - and some info to help understand how it works. In this case, it's in the library, not the compiler.

[Sam Hobbs]

Originally posted by abc_coder
you're adding to the confusion here.

No, I was responding to statements that added to the confusion. I was clarifying the context to make it more consistent with the subject.

However I will leave this for others to decide, at least for themselves. What I said is all that needs to be said.

[_uj]

What are the pros and cons of Boost.Thread and Posix? Is it possible to say which one is better in a specific situation?

[_uj]

Originally posted by _uj
What are the pros and cons of Boost.Thread and Posix? Is it possible to say which one is better in a specific situation?

And which one, if any, is likely to make it into the C++ standard library?

[dude_1967]

You know,

In this interesting post, there has not really been any major confusion, but rather a lot of interesting and related information exchange. This is expected for such a rich topic.

The original question asked if there are any available information and tutorials on multithreading in C/C++.

The answer is simply yes. However, it came to light that multithreading is by its very nature dependent on the underlying operating system and that multitasking is not yet specified as an integral part of any popular high-level-language.

There are several common multithreading interfaces provided by compilers for several popular operating systems and development environments. In the Unix/Linux/GCC environment, there is support for posix, in particular ISO/IEC 9945-1:1996 and later specifications, with support for pthreads. In the MSWIN/VC++ environment, there is support for the Win32-API Win32-threads. In addition, there are wrappers and translational libraries for various interfaces which allow for efficient cross-development among the various environments, i.e. the pthreads wrapper for Win32 in the post from abc_coder or the GNU package Common-C++ in my original post. These can all be investigated through internet research (web search) as well as printed books and other literature.

The studying developer should become familiar with the variuos flavors of multithreading and as well as possible master the existing technologies and apply them effectively for the development goals.

Sincerely, Chris.

[Mick]

Originally posted by dude_1967
These can all be investigated through internet research (web search) as well as printed books and other literature.

The studying developer should become familiar with the variuos flavors of multithreading and as well as possible master the existing technologies and apply them effectively for the development goals.

you mean somebody else acually does this? I'm shocked ...or in other words well said....

[_uj]

Originally posted by Sam Hobbs
No, I was responding to statements that added to the confusion. I was clarifying the context to make it more consistent with the subject.

I would like to add to this confussion .

I, and many with me, are using the word C++ compiler for a system which turns source code written according the rules of the C++ core language specification and the C++ standard library definition into a runnable executable.

As long a multithreading isn't part of C++ there's just one compiler issue: Is the generated code threadsafe or not? The complier couldn't care less how you accomplish multithreading in your program. This changes dramatically if or when multithreading enters C++. Then it's suddenly the compilers responsibility to provide for it.

I very much would like multithreading to become the compiler's responsibility. But until it has I'll have to navigate my way beween different external libraries and standards. Quite unsatisfactory because multithreading is such an integral part of applications today.

[_uj]

Originally posted by dude_1967
However, it came to light that multithreading is by its very nature dependent on the underlying operating system and that multitasking is not yet specified as an integral part of any popular high-level-language.

I guess you don't consider Java popular then.

[Mick]

Originally posted by _uj
I guess you don't consider Java popular then.

as popular as VB

[_uj]

Originally posted by Mick
as popular as VB

Visual Basic doesn't have multithreading in the language, but Java and C# have.

I have a Java background and I consider C++ a very good alternative to both Java and C#. Multithreading would make it even better. Not in the core language but in the standard library. Is there work going on in this direction?

[Mick]

Originally posted by _uj
Visual Basic doesn't have multithreading in the language, but Java and C# have.

I have a Java background and I consider C++ a very good alternative to both Java and C#. Multithreading would make it even better. Not in the core language but in the standard library. Is there work going on in this direction?

you made a statement about popularity...I made a sarcastic response...as I tend to do VB/Java/C# have a place, but it's not my place. It's a religious discussion...I consider the above inferior to c++, and c++ inferior to C and C inferior to assembly and so on and so forth.

[CornedBee]

Originally posted by _uj
Not in the core language but in the standard library. Is there work going on in this direction?

Boost contains the threading library, and one of the goals of Boost, as stated on their website, is to provide peer-reviewed libraries for eventual inclusion in the C++ standard.

One goal is to establish "existing
practice" and provide reference implementations so that the Boost libraries are
suitable for eventual standardization. Some of the libraries have already been
proposed for inclusion in the C++ Standards Committee's upcoming C++ Standard
Library Technical Report.

[_uj]

Originally posted by Mick
you made a statement about popularity...I made a sarcastic response...as I tend to do VB/Java/C# have a place, but it's not my place. It's a religious discussion...I consider the above inferior to c++, and c++ inferior to C and C inferior to assembly and so on and so forth.

Maybe you missed it but my statement about popularity was ironic. The problem is that I was wrong . I better correct myself before someone helps me. Multithreading is NOT part of the core Java language, it's in the standard library.

Many consider the choise of language a religious question but I don't. To me it's a purely technical decision. I'm switching from Java to C++ because it's better for my application not because Java would be inferiour to C++.

I think C++ could gain on Java and C# in popularity and that would be something all C++ programmers would benefit from (even the sarcastic). One weakness of C++ though is multithreading I think and that's why I engaged in this thread.