How to speed up C mutex? - c

Question

I has this wrong code.
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#define MAX 1000
struct TContext {
const char* Name;
int* Counter;
int Mod;
};
void* ThreadFunc(void* arg) {
struct TContext* ctxt = arg;
int* counter = ctxt->Counter;
fprintf(stderr, "This is %s thread\n", ctxt->Name);
while (*counter < MAX) {
if (*counter % 2 == ctxt->Mod) {
printf("%d ", (*counter)++);
}
}
pthread_exit(0);
}
int main()
{
pthread_t t1;
pthread_t t2;
int counter = 0;
struct TContext ctxt1 = {"even", &counter, 0};
struct TContext ctxt2 = {"odd", &counter, 1};
pthread_create(&t1, 0, ThreadFunc, &ctxt1);
pthread_create(&t2, 0, ThreadFunc, &ctxt2);
pthread_join(t1, 0);
pthread_join(t2, 0);
printf("\n");
return 0;
}
My aim is to synchronize it and get sequnce 0, 1, 2, 3, 4, 5... .
I am try to lock and unlock mutex in this way
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
void* ThreadFunc(void* arg) {
struct TContext* ctxt = arg;
int* counter = ctxt->Counter;
fprintf(stderr, "This is %s thread\n", ctxt->Name);
while (*counter < MAX) {
if (*counter % 2 == ctxt->Mod) {
pthread_mutex_lock(&mutex);
printf("%d ", (*counter)++);
pthread_mutex_unlock(&mutex);
}
}
pthread_exit(0);
}
But it works very slow(I has tl in one second).
How I can synchronize this code in more effective way? Or maybe I can optimize C-mutex?

Answer 1

A slightly more traditiona way than Chris Halls is:
pthread_cond_t cv;
pthread_mutex_t lock;
void* ThreadFunc(void* arg) {
struct TContext* ctxt = arg;
int* counter = ctxt->Counter;
fprintf(stderr, "This is %s thread\n", ctxt->Name);
pthread_mutex_lock(&lock);
while (*counter < MAX) {
if (*counter % 2 == ctxt->Mod) {
printf("%d ", (*counter)++);
pthread_cond_broadcast(&cv);
} else {
pthread_cond_wait(&cv, &lock);
}
}
pthread_mutex_unlock(&lock);
pthread_exit(0);
}
and in main:
pthread_mutex_init(&lock, 0);
pthread_cond_init(&cv, 0);
somewhere before creating the threads. This also lets you add an arbitrary number of even + odd threads without interference ( although no speedup, just intellectual curiosity ).

Answer 2

I suggest:
void* ThreadFunc(void* arg) {
struct TContext* ctxt = arg;
volatile int* counter = ctxt->Counter;
fprintf(stderr, "This is %s thread\n", ctxt->Name);
while (1)
{
int count ;
count = *counter ; // NB: volatile*
if (count >= MAX)
break ;
if ((count % 2) == ctxt->Mod)
{
printf("%d ", count) ;
*counter = count + 1 ;
} ;
} ;
pthread_exit(0);
}
Which, for x86/x86_64 at least, will have the effect I think you were looking for, namely that the two threads take turns in incrementing the counter.
The really interesting question is why this works :-)
Postscript
The code above depends, critically, on four things:
there is only one value being shared between the threads -- the counter,
the counter is simultaneously data and control -- the ls bit of the counter signals which thread should proceed.
reading and writing the counter must be atomic -- so every read of the counter reads the last value written (and not some combination of the previous and current write).
the compiler must emit code to actually read/write the counter from/to memory inside the loop.
Now (1) and (2) are specific to this particular problem. (3) is generally true for int (though may require correct alignment). (4) is achieved by defining the counter as volatile.
So, I originally said that this would work "for x86/x86_64 at least" because I know (3) is true for those devices, but I also believe it is true for many (most ?) common devices.
A cleaner implementation would define the counter _Atomic, as follows:
#include <stdatomic.h>
void* ThreadFunc(void* arg) {
struct TContext* ctxt = arg;
atomic_int* counter = ctxt->Counter;
fprintf(stderr, "This is %s thread\n", ctxt->Name);
while (1)
{
int count ;
count = atomic_load_explicit(counter, memory_order_relaxed) ;
if (count > MAX) // printing up to and including MAX
break ;
if ((count % 2) == ctxt->Mod)
{
printf("%d ", count) ;
atomic_store_explicit(counter, count + 1, memory_order_relaxed) ;
} ;
} ;
pthread_exit(0);
}
Which makes (3) and (4) explicit. But note that (1) and (2) still mean that we don't need any memory ordering. Every time each thread reads the counter, bit0 tells it whether it "owns" the counter. If it does not own the counter, the thread loops to read it again. If it does own the counter, it uses the value and then writes a new value -- and because that passes "ownership" it returns to the read loop (it cannot do anything further with the counter until it "owns" it again). Once MAX+1 has been written to the counter neither thread will use or change it, so that's safe too.
Brother Employed Russian is correct, there is a "data race" here, but that is resolved by a data dependency, particular to this case.
More Generally
The code above is not terribly useful, unless you have other applications with a single shared value. But this can be generalised, using memory_order_acquire and memory_order_acquire atomic operations.
Suppose we have some struct shared which contains some (non-trivial) amount of data which one thread will produce and another will consume. Suppose we again use atomic_uint counter (initially zero) to manage access to a given struct shared parcel. Now we have a producer thread which:
void* ThreadProducerFunc(void* arg)
{
atomic_uint counter = &count ; // somehow
....
while (1)
{
uint count ;
do
count = atomic_load_explicit(counter, memory_order_acquire) ;
while ((count & 1) == 1) ;
... fill the struct shared parcel, somehow ...
atomic_store_explicit(counter, count + 1, memory_order_release) ;
} ;
....
}
And a consumer thread which:
void* ThreadConsumerFunc(void* arg)
{
atomic_uint counter = &count ; // somehow
....
while (1)
{
uint count ;
do
count = atomic_load_explicit(counter, memory_order_acquire) ;
while ((count & 1) == 0) ;
... empty the struct shared parcel, somehow ...
atomic_store_explicit(counter, count + 1, memory_order_release) ;
} ;
....
}
The load-acquire operations synchronize with the store-release operations, so:
in the producer: the filling of the parcel will not start until the producer has "ownership" (as above), and will then "complete" (writes become visible to the other thread) before the count is updated (and the new value becomes visible to the other thread).
in the consumer: the emptying of the parcel will not start until the consumer has "ownership" (as above), and will then "complete" (all reads will have read from memory) before the count is updated (and the new value becomes visible to the other thread).
Clearly, the two threads are busy waiting for each other. But with two or more parcels and counters, the threads can progress at the speed of the slower.
Finally -- x86/x86_64 and acquire/release
With x86/x86_64, all memory reads and writes are implicitly acquire-reads and release-writes. This means that there is zero overhead in atomic_load_explicit(..., memory_order_acquire) and atomic_store_explicit(..., memory_order_release).
Conversely, all read-modify-write operations (and memory_order_seq_cst operations), carry overheads in the several-10s of clocks -- 30?, 50?, more if the operation is contended (depending on the device).
So, where performance is critical, it may be worth understanding what's possible (and what isn't).

Answer 3

How I can synchronize this code in more effective way?
You can't: the code is fundamentally inefficient.
The issue is that the amount of work that you do (incrementing an integer) is minuscule compared to the synchronization overhead, so the latter dominates.
To fix the problem, you need to do more work for each lock/unlock pair.
In a real program, you would have each thread perform 1000 or 10000 "work items" for each lock/unlock iteration. Something like:
lock;
const int start = *ctx->Counter;
*ctx->Counter += N;
unlock;
for (int j = start; j < start + N; j++) /* do work on j-th iteration here */;
But your toy program isn't amenable to this.
Or maybe I can optimize C-mutex?
I suggest trying to implement a correct mutex first. You'll quickly discover that this is far from trivial.