I am porting one Linux Application to Windows. I observed many changes need to be done in multithreading part.
what will be the equivalent structure for "pthread_t" (which is in Linux), in windows?
what will be the equivalent for structure for "pthread_attr_t" (which is in Linux), in windows?
Can you please guide me some tips while porting.
Thanks...
The equivalent to pthread_t would be (as is so often the case) a HANDLE on Windows - which is what CreateThread returns.
There is no direct equivalent of pthread_attr_t. Instead, the attributes of a flag such as the stack size, whether the thread is initially suspended and other things are passed to CreateThread via arguments.
In the cases I saw so far, writing a small wrapper around pthreads so that you can have an alternative implementation for Windows was surprisingly simple. The most irritating thing for me was that on Windows, a Mutex is not the same thing as on Linux: on Windows, it's a handle which can be accessed from multiple processes. The thing which the pthread library calls mutex is called "critical section" on Windows.
That being said, if you find yourself finding more than just a few dozen lines of wrapper code you might want have a look at the c++11 thread library or at the thread support in Boost to avoid reinventing the wheel (and possibly wrongly so).
Here is your tip - "pthread is POSIX".
Mingw has pthreads,
Cygwin have pthreads and so on.
My advice is to stick with mingw and try not to do any changes.
Related
I'm maintaining some software that runs on Windows and several UNIX platforms: Mac, Linux, AIX and Solaris. It implements a threading infrastructure on top of pthreads or Win32 threads. I'm starting to implement rwlocks in this infrastructure so that our developers can use them. So far, so good.
On Mac OS X, we originally implemented threading using normal pthreads, but found that performance was very poor, because OS X pthreads mutexes always made system calls. Apple recommended that we use GCD dispatch semaphores, and this worked just fine, with a considerable performance improvement, because waiting for a semaphore is a simple userspace operation if the semaphore is free.
However, I can't see any way to do the equivalent of rwlocks, and it looks impossible in terms of a simple semaphore. Am I missing something, or is this actually impossible?
Note: switching everything to the GCD approach with queues and blocks is not feasible. The code has to work on platforms that don't have GCD, and re-writing all the usages of the threading infrastructure, in about 170 source files, would not be practical.
Silly me, should have checked Wikipedia first. There are several ways to do it there. It is a standard computer science problem: not totally trivial, but well-understood.
fork() is a nasty libc function to implement on Win32. Fortunately Win32 CreateProcess() is rather close to fork() followed by exec().
It seems there are many different system calls for process spawning on Linux these days.
The quesion is: how do I make fork+exec portable and use CreateProcess() on Windows?
So on Unix it does something like this (cross chroot/chdir of course):
https://github.com/mindcat/pacman/blob/master/lib/libalpm/util.c#L529
And on Windows it does something like this:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499%28v=vs.85%29.aspx
Are there any existing wrappers?
Did you consider using some cross-platform libraries like glib (with spawning process facilities), Qt with QProcess, Poco, boost process, etc etc.... ?
Then you could (in principle) write source code which runs both on Windows and on Linux.
(you don't "port" fork+ exec to Windows, you only use higher level constructs provided by such libraries to create new processes).
I have to implement kernel level thread but while searching on the net I found that there are three ways to create kernel level thread in linux:
NPTL
kthread
linuxThreads
It was written somewhere that linuxThreads are now abandoned. But I am unable to find current support of NPTL & kthread. Also I am unable to find any source that can simply explain me how to use their functionality.
Which is the currently supported and good library to use kernel level thread?
Also pls share any resource for installing these library and also using them?
You are confusing two very different definitions of "kernel thread".
LinuxThreads and NPTL are implementations of POSIX pthreads for user-space processes. They use a 1-to-1 mapping of kernel scheduling entities to user-space threads. They are sometimes described as kernel threads implementations only because they create threads that are scheduled by the kernel.
LinuxThreads is unsupported and entirely obsolete. NPTL is now part of glibc, so you already have it. There's nothing special to install. You use these the same way you use any POSIX threading library, with calls to functions like pthread_create.
Actual kernel threads run kernel code. None of those libraries are relevant since they're all user-space libraries. Have a look at functions like kthread_run. There's no magic, no secret. Write kernel code the way similar kernel code is written. (Knowledge and experience in writing kernel code is needed. It's, unfortunately, not simple.)
I assume that; if you really wanted to create a kernel thread, you would already know about these things.
I think, you want to create multi-threaded applications and trying to find info about user-level multi-threading functions.
And yes, these threads you created will be managed by the kernel itself. This is what you are looking for :: POSIX Threads
I just dipped my toes into the POSIX pond and tried out POSIX threads for the first time. Until now, I'd been under the impression that there's a big architectural difference between POSIX threads and Win32 threads, but from the (admittedly little) that I tried, I didn't really see any difference.
I'm still curious though -- what are the differences (if any) between POSIX threads and Win32 threads? Are they different fundamentally, or do they just have minor differences?
There are huge differences between how threads are managed and scheduled "under the hood" in Windows NT family kernels and on many Unix kernels, but that's not the question.
If you're just talking about the interface (the services exposed by Win32 threads and POSIX threads), with some work you can almost map any POSIX thread feature to a Win32 equivalent ~1:1. And it has been done (see pthreads-win32).
One big difference I may notice is that under Win32 you use actual system calls to work with threads, instead POSIX threads' calls are part of a library (pthreads), that - under many Unix systems - calls some very low level system calls of Unix kernels (under Linux there's clone()).
Just to prove you that, unless you go very deep, pthreads is nothing so special, you can download pthreads-win32 that exposes quite the same interface of pthreads, and any function is mapped on Win32 thread APIs. And it works.
One small but crucial difference seems to be that there's no POSIX equivalent to Windows's CREATE_SUSPENDED.
I've read about Preemptive Multithreading here and here.
Is there a way to do this in Delphi and how does this compare (advantages and disadvantages) to other methods of threading in Delphi?
The "other methods" you're referring to all seem to be using the operating system's underlying threading capability -- which is preemptive. In other words, choose whichever you find most convenient, and it'll be preemptive.
Getting non-preemptive (aka cooperative) threading requires a bit of extra work, typically by converting threads to "fibers".
Modern versions of Windows are all preemptive multitasking operating systems. This means that threads and processes (where a process to exist requires at least one thread of execution) are all scheduled and preemptively run.
So "is there a way to do this in Delphi" has the following answers:
Your singlethreaded Delphi application is already preemptively scheduled with the other applications
If you write a multithreaded Delphi application, it also will be. You would have to go to considerable effort to write a non-preemptive model, such as a cooperative threading model in your application. One approach might be to use coroutines; here is an example using Delphi 7.
The best answer is use TThread or any native Windows thread or wrapper around them. You will have preemptive multithreading.
All the models in your link use normal Windows threads and I suspect your question means you're confused about different threading techniques, which are mostly techniques for communication or running tasks (jobs of work that are run on other threads.) If this is the case, you might want to either update your question or ask another looking for an explanation of these models.
Have you looked at User-Mode Scheduling which was introduced in Windows 7. Fibers basically don't really work. There's lots of information on this on the MSDN site and I seem to recall a few videos on Channel 9.