Trouble with Multithreading

mmozeiko
1) no. This can be used safely on multiple threads. That's the point of mutex - to synchronize threads. If multiple threads will call lock at the same time, only one of them will succeed, and rest of them will wait until first one calls unlock. Same on Windows with critical sections or mutex objects.

2) yes, you should use dedicated mutex per condition object. There is alternative way to build "condition variables" on Linux - using semaphores. Or evenfd. eventfd is very similar to CreateEvent functionality on windows. eventfd also allows to wait on multiple event handles at the same time (with select/poll/epoll) - same as on Windows with WaitForMultipleObjects.

3) events and conditional variables is very different thing. Windows event is equivalent to eventfd on Linux. And pthread_cond_t is equivalent to CONDITION_VARIABLE on Windows.

Your code seems ok, but remember to lock/unlock mutex around signal/broadcast/wait functions. Also don't call signal/broadcast at the same time. Use only one of them depending on how many threads you want to wake up. Signal wakes up only one of the threads that waits. Broadcast wakes up all of them.

mmozeiko
Actually its other way around - condition variables are much more lightweight than events. Its better to design your synchronization directly to use semaphores or condition variables instead of events (or use conditional varibles to simulate events).

As I said - if you want Windows event like synchronization, then you can simply use eventfd. No need to simulate them. Here's example how to use it (WARNING - no error checking): https://gist.github.com/mmozeiko/b2a72ab9fe52e6c2b88fff5ec8eaeba7
eventfd actually is more powerful than Windows event, it can handle more complex synchronization situations.

Btw, I hate when platform abstraction libraries create their own types for events / files / sockets / etc. Because that prevents you to use a lot of good synchronization situations. All modern OS'es allow to wait simultaneously on event and file/socket and other handles (WaitForMulipleObjects/epoll). On Windows both file and event has HANDLE type. On Posix - int type. Sure, you can drop down to actual OS primitives if library allows to access struct members, but then its kind of pointless to use abstraction library at all. Basically library at this point makes you to write more inefficient code, but using multithreading/events/etc should be about writing more efficient code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// Header
typedef void *fplEventHandle;

// Impl
typedef struct fplInternalEventHandle {
#if defined(FPL_PLATFORM_WIN32)
  HANDLE win32EventHandle;
#elif defined(FPL_PLATFORM_LINUX)
  int linuxEventHandle;
#else
  int dummy;
#endif
} fplInternalEventHandle;

fplEventHandle fplEventCreate() {
  fplInternalEventHandle *internalHandle = (fplInternalEventHandle *)malloc(sizeof(fplInternalEventHandle ));
  // ...
  fplEventHandle result = (void *)internalHandle;
}

void fplEventDestroy(fplEventHandle *eventHandle) {
  fplInternalEventHandle *internalHandle = (fplInternalEventHandle *)eventHandle;
#if defined(FPL_PLATFORM_WIN32)
  internalHandle->win32EventHandle ...
#else if defined(FPL_PLATFORM_LINUX)
  internalHandle->linuxEventHandle = ...
#endif
  free(internalHandle);
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Header
typedef struct fplEventHandle {
#if defined(FPL_PLATFORM_WIN32)
  HANDLE win32EventHandle;
#elif defined(FPL_PLATFORM_LINUX)
  int linuxEventHandle;
#else
  int dummy;
#endif
} fplEventHandle;

// Impl

bool fplEventInit(fplEventHandle *handle) {
#if defined(FPL_PLATFORM_WIN32)
  handle->internalHandle.win32EventHandle ...
#else if defined(FPL_PLATFORM_LINUX)
  handle->internalHandle.linuxEventHandle = ...
#endif
}

void fplEventDestroy(fplEventHandle *handle) {
  // ...
}

Finalspace
But why is it ineffecient to have access to the underlying OS primitives? I find it very ineffectient to introduce a allocation just to hide away the internal OS specific handles. Thats what most libraries do, like for example SDL. They will never show the internal stuff.

ratchetfreak

Finalspace
But why is it ineffecient to have access to the underlying OS primitives? I find it very ineffectient to introduce a allocation just to hide away the internal OS specific handles. Thats what most libraries do, like for example SDL. They will never show the internal stuff.

It's not about efficiency but about encapsulation and robustness, having direct access to the OS handles means the usercode could destroy them or do other nefarious things with them that would invalidate some of your internal invariants and break code in strange ways that can be very hard to debug.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Header
typedef struct fplInternalWhateverHandle {
  ... tons of internal stuff
} fplInternalWhateverHandle;

#if defined(FPL_HIDE_IMPLEMENTATION)
typedef void *fplWhateverHandle;
fplWhateverHandle fplCreateWhatever();
#else
typedef fplInternalWhateverHandle fplWhateverHandle;
bool fplInitWhatever(fplWhateverHandle *handle);
#endif

// Implementation

bool fplInitWhatever(fplWhateverHandle *handle) {
  fplInternalWhateverHandle *internalHandle = (fplInternalWhateverHandle *)handle;
  ...
}

fplWhateverHandle fplCreateWhatever() {
  fplInternalWhateverHandle *handle = (fplInternalWhateverHandle *)malloc(sizeof(fplInternalWhateverHandle)));
  ...  
}