Is this a correct implementation of mutexts?

**SuchtyTV** · 07-08-2019

Hey,

given this code:

Code:

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


int test = 0;
pthread_mutex_t lock;


void* jobOne(){
    while(1){
        pthread_mutex_lock(&lock);
        printf("%d", test);
        pthread_mutex_unlock(&lock);
    }
    return NULL;
}


void* jobTwo(){
    while(1){
        test++;
    }
    return NULL;
}


int main(int argc, const char * argv[]) {
    pthread_t thread01;
    pthread_t thread02;
    
    pthread_mutex_init(&lock, NULL);
    pthread_create(&thread01, NULL, &jobOne, NULL);
    pthread_create(&thread02, NULL, &jobTwo, NULL);
}

I have serveral question:

1. Does mutextlock mean, that all other threads are not getting exceuted as long as the mutext ist not locked? I presume no.

2. How can I code, that if the current mutext is locked, the thread seeing it is locked shall do something else?

3. How do I express the following thing:
"If the mutext is locked, wait until it is unlocked, but then do not lock it when entering the critical area"?

4. Why does the process get killed by the OS?

5. Why does p_thread_create demands a void * (void) at all

I also have issues with void pointers:

If i point to a position in space, where no function is but should be, what would happen to the process?

What if I point with a function pointer to something where data should be, meanwhile passing arguments, like:

Code:

void func (void(*f)(int));

Thanks!

**Niccolo** · 07-08-2019

@SuchtyTV,

You should consider pthread_join (in main, after the threads are created). This is done for each thread you launch. Without it, the create's return and nothing blocks the application from exiting main. Join basically says "wait for the threads created to complete before continuing"...it's outside your question about the mutexes.

Otherwise, you have the basic example use of mutex, by locking and unlocking.

As to your questions:

1) In a way....it means that at the moment competing threads attempt the lock, if a lock is already held, the OS does not schedule the pending thread(s) for execution - they're blocked. They'll be re-scheduled for execution when a the lock becomes available. Some attention may be required for recursive support on occasions, because by default calling a second lock on the same mutex where you already have a lock creates a deadlock, unless recursive support is called for explicitly.

2) Research pthread_mutex_trylock.

3) Makes little sense. The mechanism you may be interested in are signals, not lock checking. Signals apply to "waitable objects", which is where you can "block" a thread until a signal is received, ostensibly a signal sent when a lock has just been released

4) There's no context in which to discuss what you mean, but perhaps you're talking about the behavior I mentioned about the missing "join"

5) Your question here is a bit vague. The void * argument is for the function being called as the thread's main function, and as this could be any type, C would require you "view" that as a void * for general applicability. For functions that don't require a parameter, supply a NULL. As to void pointer ambiguity, that's natural to the nature of the CPU - a pointer has no type to the CPU, and C's reliance upon void * is generally associated with that fact, making it incumbent upon the programmer to be sure casting is appropriate. Any misuse can lead to segmentation faults (reference to invalid memory that means nothing valid).

Thread: Is this a correct implementation of mutexts?

Thread Tools

Search Thread

Display

Is this a correct implementation of mutexts?

Similar Threads

is my C++ quicksort implementation correct?

implementation our own malloc implementation with out using predefined malloc routine

C and implementation

help with implementation

implementation?

Tags for this Thread