Linux provides Portable Operating System Interface (POSIX) semaphores, as well as pthread conditional variables to map the Win32 semaphore APIs. Both have their share of pros and cons. Get detailed code examples illustrating how to map Win32 to Linux with respect to semaphore application program interfaces (APIs).
Move Win32 C/C++ apps to Linux Part 3: Semaphores
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Windows people aren’t seriously writing all multithreaded stuff with semaphores? No wonder applications often lock up (like explorer on XP)!
Semaphores are such an unintuitive, low-level, error-prone solution that I thought only basic CS classes about OSes would still use (well, and the occasional program that uses direct hardware access or shared memory for a little more performance, like databases).
Does Windows have some kind of messaging too (like POSIX read()/write() or Mach messages)? There is a reason why there are communication calculi (CSP, Pi-calculus and others). You can easily prove model multithreaded programs and even prove certain characteristics, such as that a program can’t deadlock etc.
Another example of a system gone from excessive semaphore use to messaging (for the kernel architecture) is DragonflyBSD (in contrast to FreeBSD 5).
Windows people aren’t seriously writing all multithreaded stuff with semaphores?
Nope.
It is now clear to me. The IBM Authors are on crack.
They talk about “Porting” a app but they end up saying that you have to rewrite almost all of it to have anything that works. You could recompile it with Winelib and start adding Posix features and slowly remove the Win32 code one module at a time. Posix FileSystem support? Winelib has it in shell32. Need to call GTK,QT,OpenSSL or any other Unix lib? You can dlopen a Unix library directly from Winelib.
Semaphores are such an unintuitive, low-level, error-prone solution that I thought only basic CS classes about OSes would still use (well, and the occasional program that uses direct hardware access or shared memory for a little more performance, like databases).
good point. let’s get rid of those tricky spinlocks too, right?
“Does Windows have some kind of messaging too (like POSIX read()/write() or Mach messages)?”
It’s called COM/DCOM – too bad Microsoft got rid of the Windows API with .NET bye bye Windows API …
Actually you need spinlocks to (efficiently) implement semaphores and messaging.
I just think that generally programmers should use higher-level concepts. In-kernel messaging should be really fast, as it’s basically just setting one variable (message) and doing a semaphore operation to wake up the receiver, but you wouldn’t have to worry about all that synchronization stuff yourself.
Don’t know if your spinlock-post was ironic, though (sounds like it).
Do you follow UKent’s work, they seem to have various implementations of CSP in Java, and C and other projects. It seems if you do your CS degree there, you get to do something interesting in concurrent compilers & OS work.
Transverter looks like a very light weight Occam model.
Otherwise I’d agree with you, using semaphores for concurrency is way worse than using gotos instead of usual structured statements (unless absolutely necessary).
>Actually you need spinlocks to (efficiently) implement semaphores and messaging.
In most of the CSP implementations as I understand it, the design includes a process scheduler, so the moment you hit ? or ! you syncronize, if the channel is not ready, you get descheduled, the only time wasted is the overhead support of having all this support, which seems to be getting lighter with newer versions.
better still if the CSP was in the cpu again
DragonflyBSD is def on future study list.
johnjakson at transputer2 dot com
…the complete rewrite of the GUI is likely a bigger issue for the legions of coders porting from Win32 to linux…legions as in very very very very few.
You’re joking, right?
A decent app should have separate model/controller and view parts, so a port to MFC, Swing, Cocoa, GTk or Qt should be not too much work.
The bigger part of any application is getting the logic right (although the system interfacing + GUI might have a much higher learning curve, as most APIs suck and aren’t portable, unlike the logic).
Ulrich, most of the code in GUI apps is actually to do with the GUI and not the underlying logic. This is especially true for things like database apps. Porting to a new widget toolkit basically is a rewrite.
Whatever you all say, but I like this kind of articles. From technical side it contains very usable information, when one really needs to port some code; from philosophical side it once again proves that both these OSes have comparable inside architecture (note that I didn’t say “similar”). Of course porting low-level code means rewrite, but rewriting non-UI (=”linear”) code is usually easy.
GUI portabilty is quite different thing – it heavily depends on app logical design. If application is well structured, then this is not big problem (I mean not time-wise, but technically – usually rewrite is needed anyway); many apps unfortunately are complete mess inside.
I’ve been watching one FOSS P2P project for some years – all this time “separating core and gui” is requested, but always rejected – initial app design doesn’t allow this. Well, linux port of this project (on vxVidgets) likely managed to do this anyway:)
Definitely useful article.
Separating core and GUI — that’s the way!