hi all:
can anyone supply me the links on multi-threaded application tutorials in C++/C or just any tutorials on Threads in C++/C
Printable View
hi all:
can anyone supply me the links on multi-threaded application tutorials in C++/C or just any tutorials on Threads in C++/C
Well...did you try to e.g. google for it? There should be more than enough links to choose from...
Multithreading is OS dependent. In other words, the syntax is different for Windows, Linux, Solaris, etc.
What do you want to know?
Kuphryn
Yes. Internally they have differentQuote:
Originally posted by kuphryn
Multithreading is OS dependent. In other words, the syntax is different for Windows, Linux, Solaris, etc.
What do you want to know?
Kuphryn
implementations for threads. Nevertheless, Linux and Solaris have the same POSIX-compliant thread api - pthread_*. U can use pthread interface for windoze applications, because it has POSIX subsystem (well, it's based on the old posix specification, though). So U can use pthread api for all these systems. ;)
Okay.
Kuphryn
First, if you can get the book:
ISBN: 0471180122
Title: Object-oriented multithreading using C++
Author: Hughes, Tracey
Publisher: J. Wiley
Then that is supposedly platform-independent (see ACCU Reviews: Object-Oriented Multithreading Using C++).
I don't know what the CodeGuru articles have but it is nearly certain there is useful stuff there.
Otherwise you can look through the links I have gathered into my Other C++ Sites and Other Windows Sites pages; you can probably find some tutorials and such but it might take a couple of hours.
I asked the same some time ago,
http://www.codeguru.com/forum/showth...multithreading
You need to use the thread-safe versions of all libraries you link to your program.
If you want portable multithreading you can use the Boost libraries. WxWindows (a portable GUI toolkit) also has portable threading primitives.
Multithreading exists in C and I think there is a possibility that it will be added to C++. As far as I know, the Boost library version is a possible implementation of the future standard.
That's the goal of many boost libraries, to make it into future versions of the standard.
I've never heard of Windows implementing pthreads, it certainly isn't in the documentation.
But there are several other cross-platform libraries providing multithreading: the Netscape Portable Runtime (base for Mozilla) and the Apache Portable Runtime (base for Apache2 web server).
http://www.mozilla.org/
http://www.apache.org/
Aren't those just examples of thread-safe libraries which use threading internally? They don't assist you in making your own general threading application, instead they provide functionality for specific application domains.Quote:
Originally posted by CornedBee
But there are several other cross-platform libraries providing multithreading: the Netscape Portable Runtime (base for Mozilla) and the Apache Portable Runtime (base for Apache2 web server).
Thanks for an interesting post.
Unfortunately, the Microsoft compilers do not have support for posix.
GNU offers a common envrionment for threads and sockets. It is called Common-C++. I used it once. As with most GNU packages, it is very rich and complete, resulting in a large and cumbersome package. It might be over-dimensioned for your application. I do not have a lot of experience with Common-C++ since it was always best for my developments to write smaller custom solutions.
Nevertheless, you might want to take a look.
http://www.gnu.org/software/commoncpp/
Sincerely, Chris.
:)
I donot understand from your point of view why some compiler should support POSIX. The OS should has such a support. There are no any explicit reasons for the compiler to do that. Even M$ Winodoze supports (oh at least I know that's true for NT) one of the first POSIX standards.Quote:
Originally posted by dude_1967
Unfortunately, the Microsoft compilers do not have support for posix.
The OS may give such a support, providing a set of libraries. What concerns to posix threads, Linux has a library called pthread, FreeBSD includes these functions in the libc_r library. All U need to do is to re-compile your program, linking it with a library specified for the current OS.
So I wonder why people want to get such kind of support from the compiler, because one thing it should provide for that (and that's enough) is the ability of linking with the external library.
dimm_coder,
This is a very rich topic which brings a lot of valid opinions to light, since multithreading is often viewed as a programming incarnation which is OS-dependent. On the one hand, a lot of developers could benefit from a common environment for multithreading which is compiler-independent. On the other hand, mandating compiler support for multithreading idioms requires the implementation of programming elements which are very near if not identical with operating system elements.
It would be hard to draw the line between OS and compiler---nearly impossible for smaller microcontroller architectures for which there is no typical underlying OS.
Posix is already specified. This is why I find the support of Posix to be a good thing on large, well established compilers for platforms such as Unix.
Sincerely, Chris.
:)
If I'm not mistaken, POSIX is a standard interface an OS should provide, not a compiler.
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.Quote:
Originally posted by dimm_coder
So I wonder why people want to get such kind of support from the compiler, because one thing it should provide for that (and that's enough) is the ability of linking with the external library.
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.Quote:
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.
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.
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.Quote:
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.
[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.
No, I was responding to statements that added to the confusion. I was clarifying the context to make it more consistent with the subject.Quote:
Originally posted by abc_coder
you're adding to the confusion here.
However I will leave this for others to decide, at least for themselves. What I said is all that needs to be said.
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?Quote:
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?
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.
:thumb:
you mean somebody else acually does this? I'm shocked :p ...or in other words well said....Quote:
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.
I would like to add to this confussion :D.Quote:
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, 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.
I guess you don't consider Java popular then. ;)Quote:
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.
as popular as VB :rolleyes:Quote:
Originally posted by _uj
I guess you don't consider Java popular then. ;)
Visual Basic doesn't have multithreading in the language, but Java and C# have.Quote:
Originally posted by Mick
as popular as VB :rolleyes:
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.Quote:
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?
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.Quote:
Originally posted by _uj
Not in the core language but in the standard library. Is there work going on in this direction?
Quote:
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.
Maybe you missed it but my statement about popularity was ironic. The problem is that I was wrong :p. I better correct myself before someone helps me. Multithreading is NOT part of the core Java language, it's in the standard library.Quote:
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.
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.
Quote:
Originally posted by _uj
One weakness of C++ though is multithreading I think and that's why I engaged in this thread.
yes I missed your irony..probably because it wasn't ironic
:p
sorry where is c++ lacking in multithreading? heh heh...that's a trick question...because no lanquage is mutilthreading, what's that they say? it's the economy stupid? well it's the OS...
Yes I'm aware of this but when I looked at proposed additions to the C++ standard library I couldn't find anything about multithreading at all.Quote:
Originally posted by CornedBee
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.
and you won't. I thought I already said it, but it is not a lanquage that dictates multithreading, but an operating system. I can write an OS called FOO...and FOO does not support multithreading, and you say your going to provide a lanquage that will support multithreading on FOO?Quote:
Originally posted by _uj
Yes I'm aware of this but when I looked at proposed additions to the C++ standard library I couldn't find anything about multithreading at all.
Well, lets call it a draw then because I didn't found your comment very sarcastic.Quote:
Originally posted by Mick
yes I missed your irony..probably because it wasn't ironic
:p
I'm sorry to inform you that you're wrong. A programming language is a formal definition of an abstract computer. This abstract computer doesn't even have to exist in the form of real software and hardware. It's fully possible to introduce the concept of concurrency in a language, and it's done all the time, without even the slightest part of a OS in sight.Quote:
sorry where is c++ lacking in multithreading? heh heh...that's a trick question...because no lanquage is mutilthreading, what's that they say? it's the economy stupid? well it's the OS...
if you say so...Quote:
Originally posted by _uj
Well, lets call it a draw then because I didn't found your comment very sarcastic.
ahh I think you need to back up and rethink this. We are talking multi-threading are we not? careful now...Quote:
I'm sorry to inform you that you're wrong. A programming language is a formal definition of an abstract computer. This abstract computer doesn't even have to exist in the form of real software and hardware. It's fully possible to introduce the concept of concurrency in a language, and it's done all the time, without even the slightest part of a OS in sight.
A thread is just a line of execution. It can exist both as an abstraction at the language level and as a physical reality at the software/hardware level.Quote:
Originally posted by Mick
ahh I think you need to back up and rethink this. We are talking multi-threading are we not? careful now...
But I'm sure you have some other definition ready that once and for all will tell us what multi-threading really is about, so don't keep us waiting, just spill it.
First on the list is pre-emptive multitasking. Multiprocessing in 16-bit Windows is very noticeably inferior to multiprocessing in a system that supports pre-emptive multitasking, and pre-emptive multitasking requires that interrupts and such be processed.Quote:
Originally posted by _uj
But I'm sure you have some other definition ready that once and for all will tell us what multi-threading really is about, so don't keep us waiting, just spill it.
Related to that is asynchronous I/O. When doing I/O, if an operating system does nothing but wait for a read or write to complete (such as what DOS does) , then perfoarmance would be significantly degraded. Therefore to solve the problem the compiler would need to implement device I/O, which would be the equivalent of writing an OS.
hmm fantasy versus reality...which to choose....I guess since we are talking the abstract...I'm god...Quote:
Originally posted by _uj
Well, lets call it a draw then because I didn't found your comment very sarcastic.
I'm sorry to inform you that you're wrong. A programming language is a formal definition of an abstract computer. This abstract computer doesn't even have to exist in the form of real software and hardware. It's fully possible to introduce the concept of concurrency in a language, and it's done all the time, without even the slightest part of a OS in sight.
no it's the chicken and the egg here. Your comment said Java is multithreaded (or should I say you want the compiler/lanquage to dictate multithreading)...that's fine, but why is it multithreaded? Is it the lanquage or the operating system that makes it so? to write an OS you need a lanquage, to introduce multithreading in your OS you need to introduce multithreading in the underlying OS via the lanquage. Other lanquages can use this underlying support to say I'm multithreaded. But if you write an OS that doesn't support multithreading then whatever lanquages you have will not support multithreading, no matter how much they try. I think it's a pretty simple and clear concept...not sure what your point is.Quote:
Originally posted by _uj
A thread is just a line of execution. It can exist both as an abstraction at the language level and as a physical reality at the software/hardware level.
But I'm sure you have some other definition ready that once and for all will tell us what multi-threading really is about, so don't keep us waiting, just spill it.
Actually, that depends on the model of multithreading, U want to achive. There are a lot of realizations of thread libraries on the user-space level (1:M model). Of course, these threads are not full-functional, OS doesn't know anything about them, thus they have drawbacks, but still can be usefull for some cases.Quote:
Originally posted by Mick
But if you write an OS that doesn't support multithreading then whatever lanquages you have will not support multithreading, no matter how much they try.
dimmers...did you not just make my case? As I stated before, religious discussion...lets all say we differ in opinion and move on....Quote:
Originally posted by dimm_coder
Of course, these threads are not full-functional, OS doesn't know anything about them, thus they have drawbacks, but still can be usefull for some cases.
/And then we'll not take south carolina....yeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa opps...
Yea. but I donot propose to place that kind of support in languages... but yea ..that's a religion.Quote:
Originally posted by Mick
dimmers...did you not just make my case? As I stated before, religious discussion...lets all say we differ in opinion and move on....
/ Imagine ... no religion too...
you can't imagine no religion without religion... :pQuote:
Originally posted by dimm_coder
/ Imagine ... no religion too...
/Imagine all the people...
Actually it's the virtual machine, so we'd best call it the OS.Quote:
Your comment said Java is multithreaded (or should I say you want the compiler/lanquage to dictate multithreading)...that's fine, but why is it multithreaded? Is it the lanquage or the operating system that makes it so?
Your "simple and clear concept" is just plain wrong. You don't need an OS with multithreading support for multithreading to exist in a programming language. That's my point and here's my reason why again:Quote:
Originally posted by Mick
...that's fine, but why is it multithreaded? Is it the lanquage or the operating system that makes it so?
I think it's a pretty simple and clear concept...not sure what your point is.
A programming language is a formal definition of an abstract computer. It's this abstract computer you think of when you program. You don't need an OS to think, do you? To actually run the program you'll need an implementation of the abstract computer in some combination of software and/or hardware but that's a different story.
It's when you fail to separate abstract concepts from possible implementations you end up with the kind of mishmash "theory" you presented.
you don't need a program to think, do you?Quote:
Originally posted by _uj
A programming language is a formal definition of an abstract computer. It's this abstract computer you think of when you program. You don't need an OS to think, do you?
it's when you fail to seperate the abstract from real world concepts that you come to this mishmashed theory...Quote:
To actually run the program you'll need an implementation of the abstract computer in some combination of software and/or hardware but that's a different story.
It's when you fail to separate abstract concepts from possible implementations you end up with the kind of mishmash "theory" you presented.
my god are you hearing yourself??? If I deny multi thread creation at the OS level, your some how going to create multithreading...Quote:
Originally posted by _uj
Your "simple and clear concept" is just plain wrong. You don't need an OS with multithreading support for multithreading to exist in a programming language. That's my point and here's my reason why again:
/Here comes the science...
If a language standard includes multithreading and a specific OS does not support multithreading then that OS does not support the standard.Quote:
Originally posted by _uj
You don't need an OS with multithreading support for multithreading to exist in a programming language.
I think we can all agree that we (_uj and me) disagree... and there is no point for further disussion.
Okay...I think everything has been said here, thus, we can stop at this point.
Thank you very much.