POSIX vs. Sayegh gmail. All these articles are mentioned in the References slide. What is Thread1. What is Thread2. A thread is created by OS to run a stream of instructions. Threads contain smaller set of information 7. Scheduling Properties 8. Registers 9. Stack Signal actions Has its own independent flow of control as long as its parent process exists and the OS supports it Changes made by one thread to shared system resources will be seen by all other threads.
File open or close at the process level. Memory Sharing Same address, same data. Two pointers having the same value, exist in the same virtual memory and point to the same data.
No copy is needed! Synchronization required. Win32 vs. Historically, hardware vendors have implemented their own proprietary versions of threads. Differences between drafts exist! Especially many scheduling mechanisms exist user and kernel-level threads.
Mapping Win32 to Pthreads1. Mapping Win32 to Pthreads2. Mapping Win32 to Pthreads3. Conditional Variables: While mutexes implement synchronization by controlling thread access to data, condition variables allow threads to synchronize based upon the actual value of data.
Thread-based multitasking deals with the concurrent execution of pieces of the same program. A multithreaded program contains two or more parts that can run concurrently. Each part of such a program is called a thread, and each thread defines a separate path of execution.
To execute the c file, we have to use the -pthread or -lpthread in the command line while compiling the file. It is not possible to have a deadlock involving only one single process. After sending the request to cancel the thread you should check the return code to confirm that the thread was actually cancelled or not.
It is cross-platform. For instance, pthreads library by default is not available on Windows. Using thread guarantees that available implementation will be used. Most Win "applications" are full of race conditions and utter silliness ala dying "spinlocks", and etc.
I was, of course, hoping to start some controversy and generate some discussion on the merits of both Pthreads and Win32 threads assuming that proponents of both were involved with the Threading Forum.
Alas, almost everyone that has taken the time to voice an opinion has agreed with me. Not much chance of controversy there. I've looked at the poll on what threading API is used most by respondents and found almost twice as many Win32 users as Pthreads users. Are there no Win32 advocates or do they agree with what the Pthreads supporters have said, but use the API for reasons beyond their control?
I have no answers and I really didn't want this to degenerate into a bashing of either API. Perhaps we can just let this topic fade away quietly? Part of the problem is that you don't really have a choice what platform you use. To say that you have a choice on win32 because you can use the pthread-win32 or whatever they call it package. For one reason, see this article.
For another, there's too much of a runtime difference between unix and windows. You'd have to port the entire unix runtime to windows. That's already been done. It's called linux. If all you want is a condition variable, then you should just implement a condition variable without all the posix stuff. BTW, I did implement a win32 condvar without the problems mentioned in the article, so it can be done. Even if you don't read the article, you can take it that it's non-trivial enough that Microsoft put condvars in C , otherwise there would have been no way to port Java apps to C using win32 events and still have those apps work.
Non-trivial enough that it was an interesting challenge for me to do it in C. There is, however, some things that win32 threads did better then posix threads. The WaitForMultipleObjects allows you to decouple the signaling and waiting threads better. In posix, if some thread wants to wait on multiple conditions, there has to be a condvar especially for that and the signaling thread has to know about it.
In win32, the signaling thread only has to signal the events it knows about and not have to worry about other threads waiting for mulitple events, though there still the problem of events being lossey.
Also win32 threads are more orthagonal. The kludges to make those work together are incredible. Joe Seigh ps. I you want more participation in these forums, you are going to have to make this website more browser friendly.
It is a major undertaking to post anything here. Joe, thanks for posting the article pointer. Even if you aren't interested in the creation of POSIX condition variables with Win32 constructs, it is informative about the problems and subtleties of programming with threads.
While a simple and easy example to understand, it is unfortunate to some degree that the authors chose to implement a semaphore object with the POSIX condvar when Win32 already supports such a thing as well as POSIX, I believe. The first is as the article mentions, if a thread waiting on the condition variable is signaled, it must first recheck the condition being waited on before proceeding.
In order to be safe and catch all possible situations, every time some operation is performed that may change the evaluation of the condition for a waiting thread, a signal should be generated. The thread that wakes up reacquires the lock, checks the condition in the while test and either proceeds or finds the condition lacking and goes back to the wait state.
It is rare, but still possible that a thread will return from waiting without a signal or broadcast being generated by another thread on the condition variable. Since no thread has signaled, it is unlikely that the condition being waited on has been satisfied, so the while test forces the thread back into the wait state. Having learned and used Pthreads before Win32 threads, I was initially dismayed that there was no condition variable or something like it in the Win32 threads API.
They both have many things in common that may be expressed in slightly different syntax, and there are features in each that aren't in the other. This just means that you need to modify your approach when porting from one language threading API to the other.
Some might, but the majority would just work within the confines of what is available. Have you seen or tried the Red Hat implementation of Pthreads on Windows?
There is a link in an earlier post. While the original intent was not to judge the two different threading APIs on performance since, as was pointed out, they are implemented on two different runtime systems , but now we have an implementation of both on the same OS. I linked it to a Pthreads program on Windows and it ran correctly. It's a pretty easy way to get Pthreads programs working on Windows.
I didn't do any performance experiments but I don't expect a significant performance loss. The Red Hat Pthreads implementation just wraps equivalent Windows threading functions. I did an experiment to test whether the Intel Thread Checker could analyze a Pthreads program on Windows. Data races were deliberately introduced into the program. Thread Checker correctly identified the data races, their locations in the code, and the variables involved. I really don't like either. I get the advantages of complete portability and an API that I consider perfect.
I agree that abstracting native thread libraries in classes is a good thing, but if you have to move a C, Pthreads code to Windows, the Red Hat Pthreads DLL makes porting a lot easier. A futher reason is if you happen to be so lucky??? I have reported a few issues to them that are being investigated, but they are quite minor.
Short version: If you want to develop for multiple platforms, including Windows, Linux, Novell, MacOS and a few others, pthreads is the only way to go.
0コメント