Home > Net >  pthread_attr_setschedparam return non-zero
pthread_attr_setschedparam return non-zero

Time:02-16

I executed this code on Virtual machine (Ubuntu) and I get a non-zero for e, but when I executed it on my host OS (MacOS) I get a zero. Can someone explains what causes it to return a non-zero?

  pthread_attr_init(&arrt);
  struct sched_param param;
  pthread_attr_getschedparam (&arrt, &param);
  int e = pthread_attr_setschedparam (&arrt, &param);

Edit -

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

void* function1(void* arg) {
    struct sched_param param;
    int priority, policy;
    pthread_getschedparam(pthread_self(), &policy, &param);
    priority = param.sched_priority;
    printf("thread priority: %d\n", priority); // I get 0
}

int main() {
    struct sched_param param;
    pthread_t thread;
    pthread_attr_t arrt;

    pthread_attr_init(&arrt);
    pthread_attr_getschedparam(&arrt, &param);
    pthread_attr_setschedpolicy(&arrt, SCHED_FIFO);
    param.sched_priority = 10;
    int e = pthread_attr_setschedparam(&arrt, &param);
    printf("e: %d\n", e); // now I get 0
    pthread_create(&thread, &arrt, &function1, NULL);
    pthread_attr_destroy(&arrt);
}

CodePudding user response:

Unix originally didn't have any support for threads; then a bunch of different Unix implementations (mostly from commercial vendors) added support for threads in their own different/incompatible way; then POSIX came along (after it was too late) and tried to create their "pthreads" standard, but because it was too late (or because they didn't want to upset any of the existing implementations) their "standard" became flexible enough to support all the pre-existing implementations, effectively making the standard a worthless joke for things like scheduling policies and thread priorities.

MacOS is mostly designed for "desktop like" scenarios where thread priorities are important (e.g. under heavy load, you do not want to wait while 1234 other threads use their time slice before an application gets time to respond to a key press), so it's likely they got scheduling right. Linux grew up with "all threads are equal, let's be fair and give all tasks an equal share of CPU time" nonsense and (for the default scheduling policy) mostly ignores explicit thread priorities (and IO priorities), and doesn't comply with POSIX specs in some parts.

To fix the problem, you need OS specific code or worse. Specifically, for Linux, it's probably better to use nice() (which is supposed to be for the process as a whole and supposed to effect all threads in the process, but doesn't because Linux doesn't comply with POSIX specs) and not bother attempting to use pthread's thread priorities; partly because the only way to get them to be actually useful is to create a real-time thread (that requires special privileges that no normal software should need).

Can someone explains what causes it to return a non-zero?

Essentially; different operating systems support (or don't support) the POSIX specs differently.

  • Related