CODEWITHSUNDEEP
clinuxwindowsconcurrency
Brian Brown
Brian Brown

Reputation: 4311

Concurrent programing in plain C - Windows / Linux

I have a function, lets say, callMe(args). I would like to be able to call my function 100 times in the same time (concurrent programing). My function is written in plain C. I want to make it concurrent for Windows and Linux.

Is there any built in support for this in standard C library? Or can you provide some advices, how should I do this in Linux/Windows?

Is pthread good for Linux environments for this?

Upvotes: 0

Views: 1892

Answers (2)

SHA2NK
SHA2NK

Reputation: 189

You have to use different functions for different platforms. Its similar like different browsers uses different kind of css property names.

So for linux/mac you can use pthread And for windows you use CreateThread

Upvotes: 0

Basile Starynkevitch
Basile Starynkevitch

Reputation: 1

You can't write a concurrent program in pure standard C99. Concurrent programming is not in standard C99; it requires some operating system specific libraries. However, the latest C11 standard (which has very few implementations today, February 2014 - I know none!) is beginning to add support for threads. On Linux systems I would suggest today to stick to pthreads.

You could use a cross-platform library (like glib from GTK) to ease porting between Windows and Linux. On Linux, it is wrapping pthreads.

I don't know Windows, but Glib -and GTK for GUI applications- is rumored to enable source-compatible coding between Windows & Linux

If your computation is embarrassingly data parallel (like some matrix numerical computations are), consider also OpenCL (notably because it can run on GPGPUs) or OpenMP. If it fits in a message passing paradigm, consider MPI

OpenCL, OpenMP, MPI are rumored to enable source-compatible coding for Linux and for Windows.

In C++11 (which is a different language than C) you have thread support, and the GCC 4.8.2 compiler is supporting them quite well. And Qt or Poco or Boost is a cross-platform C++ library, notably wrapping concurrent primitives.

Whatever concurrent mechanism you are using, beware of synchronization issues.

You always have synchronization with concurrency, at least to wait for the results of each concurrent or parallel sub-computation

Upvotes: 5

Related Questions