Extern "C" Usage With Pthreads in OO C++

Question

I have a class that handles all communication with a particular piece of hardware. The hardware requires data updates via one socket, and broadcasts its IP for handshaking purposes on a known (and hardcoded) multicast address.

As a result, the class spawns two threads, one thread which handles direct communication with the hardware and updates the data based on a member structure of the class. The other thread continuously monitors the multicast address to see if the IP has changed.

Both threads are implemented as static member functions inside the class. However, in order to use pthreads, my understanding is that they need to be declared as extern "C." That said, based on my research it is not possible to declare member functions of a class as extern "C." The way I saw some code from the engineer who worked on the project previously get around this problem is that the threaded function implementation is surrounded in extern "C." That is, extern "C" is not found in the function declaration or definition, but the whole function definition is encapsulated in extern "C" {}.

Like this:

extern "C" {
  // function goes here
}

I have several questions about this implementation as I look to improve on my understanding of the code and become better at multithreaded programming.

1. Does the extern "C" actually do anything given the way it is implemented? I've read about what the modifier actually does here: In C++ source, what is the effect of extern "C"? but in this case is it actually applicable given the fact that we are dealing with functions that are static members of a class?

2. The threaded member functions seem to get around the fact of modifying the class's member variables by doing a reinterpret_cast and creating a pointer to the class. Is this standard practice, because my red flag was raised when I saw that cast?

3. The constructor calls pthread_create() to launch the threads. I was planning on doing something like adding a static member variable which only allows one instance to communicate with the hardware at any given time. That is, I was thinking about allowing the caller to have multiple instances of the class, but only one "connected" at a time. Is this standard practice, or is there something "hacky" in my way of thinking? There will only ever be one piece of hardware attached at a given time, so there is only the requirement to have one class instance operational at a given time.

Thanks for all your help. Also, if you are just going to suggest something like "Dude, just use Boost threads, FTW," please save your breath. Although I will eventually move to a threading library, my understanding is that Boost just wraps pthreads on POSIX systems. As a result, I want to learn about using the raw threads first before I spoil myself with a library. While my main goal is delivering on time, no one said that I couldn't learn anything along the way. ;)

Edited to add:

Here's some source code describing the issue that I'm seeing for clarity. I'm still not 100% sure that the extern "C" is doing anything in this case...

In my .h:

class MyClass
{
 private:
  static void* ThreadFunc(void* args);  // extern "C" not found in declaration
  static bool instance_;
};

In my .cpp:

MyClass::MyClass() {
  if (!instance_) {
    instance_ = true;
    // spawn threads here
  } else {
    // don't spawn threads and warn user
  }
}
extern "C" {
  void *MyClass::ThreadFunc(void* args) {  //definintion wrapped in extern C
    MyClass* myclass_ptr = static_cast<MyClass*>(args);
    // ... more code
    return static_cast<void*> 0;
  }

Answer 1

Question #1

is it actually applicable given the fact that we are dealing with functions that are static members of a class?

It is applicable but not necessary. A conforming implementation (compiler) is aware of the relevant type information to either use the function pointer as-is, perform an implicit conversion or fail with an error.

Keep in mind though that additional properties can be applied when specifying a language linkage. This may include but is not limited to a specific calling convention. The standard leaves this up to the implementation however.

From $7.5/1

Some of the properties associated with an entity with language linkage are specific to each implementation and are not described here. For example, a particular language linkage may be associated with a particular form of representing names of objects and functions with external linkage, or with a particular calling convention, etc.

By specifying a language linkage you let the implementation deal with the specifics of those properties. Otherwise you would need to use language extensions to specify things like the calling convention. Even if you do that there may be other properties that are either unknown or cannot be applied through implementation specific extensions.

The language linkage also affects the type of an entity, in this case a function.

From $7.5/1

Two function types with different language linkages are distinct types even if they are otherwise identical.

In your example the pointer to the static member function is convertible to the function pointer type of the thread start function. This is why your code works properly without specifying a language linkage and without an explicit cast.

This doesn't mean you should not specify a language linkage though. If you are concerned about portability between implementations it's a good idea to use it. For instance some implementations use fastcall as the default C calling convention where others use cdecl as the default. In the absence of a language linkage specifier the code would not compile, at least not with a conforming implementation.

The example below demonstrates how the conversion will fail if different calling conventions are used. I chose using calling conventions as they are the easiest to express in an example.

#include <iostream>

#if defined(__GNUC__)
#define FASTCALL __attribute__((fastcall))
#elif defined(_MSC_VER)
#define FASTCALL __fastcall
#endif

extern "C" 
{
    typedef void (*FUNC1)(); // Default C calling convention
    typedef void (FASTCALL *FUNC2)();  // fastcall calling convention
    void do1(FUNC1 f) { f(); }
    void do2(FUNC2 f) { f(); }
}

struct X
{
    static void test() {}
};

int main()
{
    do1(X::test);   // Ok. Implicit conversion available
    do2(X::test);   // Fail! Incompatible types. No conversion available
}

Question #2

... modifying the class's member variables by doing a reinterpret_cast and creating a pointer to the class. Is this standard practice, because my red flag was raised when I saw that cast?

Using a cast is the only way to accomplish this but using reinterpret_cast is not necessary and IMO should definitely be avoided. The thread start function passed to pthread_create takes a void pointer as it's only argument. static_cast is sufficient and much narrower in behavior.

Question #3

I was planning on doing something like adding a static member variable...

The question is subjective and how you approach this is entirely up to you. Without some code it's hard to tell whether your implementation is a hack.

As a final note...DUDE! Use teh Boost yo! :)

Answer 2

You can't declare a static member function extern C, but you can call a static member function from another function that is extern C. In the cpp file where your thread function is defined:

namespace {
extern "C" {
void* some_thread_func(void* arg) {
  return MyClass::static_thread_func(arg);
}
}}

// static member
// (You can omit this "middle-man" if "do_stuff()" is public.)
void* MyClass::static_thread_func(void* arg) {
  return static_cast<MyClass*>(arg)->do_stuff();
}

void MyClass::start_thread_func() {
  pthread_t thread;
  int error = pthread_create(&thread, NULL, some_thread_func, this);
  // handle errors, store "thread" somewhere appropriate.
  ...
}

The multiple instances / one connected question is a design issue and I don't know what design really fits the rest of your program - but I will say that Singleton seems to reflect your design requirement that there is a single device to manage.

Finally, don't use boost::thread, use std::thread ;)