2 thread simple counter incrementation with critical section inside coroutines example

[fskoras]

Please tell me what am I doing wrong?

Problem description

The program keep crashing randomly.
If I just use pthreads directly without coroutines it works without issues.

Specs

• Windows 11
• Compiler: MinGW-W64 gcc (x86_64-posix-seh-rev0, Built by MinGW-Builds project) 14.2.0

Example

#include <stdio.h>
#include <pthread.h>
#include <libco.h>

int counter = 0;                // Shared counter
pthread_mutex_t counter_mutex;  // Mutex to protect the counter

__thread cothread_t co_main;    // TLS main coroutine
__thread cothread_t co_thread;  // TLS coroutine

#define STACK_SIZE 0x40000

void co_increment_counter(void)
{
    // Lock the mutex before modifying the counter
    pthread_mutex_lock(&counter_mutex);
    counter++;  // Critical section
    // Unlock the mutex after modifying the counter
    pthread_mutex_unlock(&counter_mutex);
    co_switch(co_main);
}

// Thread function to increment the counter
void* increment_counter(void*) {
    co_main = co_active();
    
    for (int i = 0; i < 100000; ++i) {
        co_thread = co_create(STACK_SIZE, co_increment_counter);
        co_switch(co_thread);
        co_delete(co_thread);
    }
}

int main() {
    pthread_t thread1, thread2;

    // Create two threads
    if (pthread_create(&thread1, NULL, increment_counter, NULL)) {
        printf("Failed to create thread 1\n");
        return -1;
    }
    if (pthread_create(&thread2, NULL, increment_counter, NULL)) {
        printf("Failed to create thread 2\n");
        return -1;
    }

    // Wait for both threads to finish
    pthread_join(thread1, NULL);
    pthread_join(thread2, NULL);

    // Destroy the mutex after usage
    pthread_mutex_destroy(&counter_mutex);

    // Print the final counter value
    printf("Final counter value: %d\n", counter);

    return 0;
}

[Alcaro]

libco is not thread safe by default. Define LIBCO_MP in your build; either via some build system flag, or by editing libco.h or settings.h.

I'm not a huge fan of defaulting to unsafe modes. IMO we should change that, or at least document it very clearly.

(Also calling pthread_mutex_destroy but not init is probably a bad idea. Either add the init, or initialize with PTHREAD_MUTEX_INITIALIZER. Sure, it works on most pthread implementations, but it looks wrong, and you may get into trouble in other APIs if you make that a habit.)

[fskoras]

I have added this macro definition LIBCO_MP and init for the mutex and now I'm getting segmentation fault on init

I admit that I am still learning pthread so thanks for the tip :)

[fskoras]

Ok. I did some more experimentation, and here’s what I found:

To make it work with the amd64.c variant, I had to #define LIBCO_NO_SSE. This might be related to the processor I'm using (Intel Core i5-13600K).

It also works with the windows fiber.c variant, but it's significantly slower.

[Screwtapello]

My understanding is that libco coroutines are an alternative to threads, not an addition. You use libco when you want more control over when and where context switches happen, so that you don't have to worry about things like mutexes. In a program that needs threads (such as for doing background calculations or handling network activity or whatever) I'd expect all the coroutines to exist inside one thread and never interact with anything outside it.

Defining LIBCO_NO_SSE tends to lead to crashes unless you can somehow guarantee that none of your code will use SSE features (which is increasingly rare), I would advise against doing that.

[Screwtapello]

It would be nice if libco would automatically play nicely out of the box with things like threads, but the whole point of it is to be faster by doing less: don't handle thread contention, don't save and restore registers you're not going to touch, etc. There's already APIs that are safe and reliable in all situations — Fibres on Windows, and ucontext on POSIX. They're also much slower than libco, which is why libco exists at all.

[fskoras]

Okay, I think I now better understand what this library was supposed to be used for. Still, I was thinking in relation to what you said, that I could create some sort of 'load balancer' that would delegate small 'tasks' across all available cores. In addition to per-thread preemption, this would also allow me to manually control from what and when I yield control, enabling even more parallelism. I guess I'll have to think of a way to avoid using pthread primitives, at least when I'm in a coroutine.