1

I'd like to be able to request Linux to schedule two or more threads in the same time. I mean today when my multi-threaded program is being executed I know that in worst case only one of my threads is being physically executed (scheduled) at a time. Now I'd like to tell Linux: here is the list of thread Ids, please try to schedule them in the same time, possibly with core affinities. Does such capability exist, or has someone worked on this ?

The goal is to have one or even more task threads (dedicated to tasks) running in the same time as the main thread. The main thread would give them very short tasks to execute, like storing to or searching a hash or array. Meanwhile the main thread would go on until it would reach a dependency on one of tasks' result. If the task was really executed in parallel the dependency would not stop the main thread and the program would run faster.

With the usual scheduling scheme the tasks could be scheduled much later than the sync point and this could even run slower than a single-threaded version.

Thanks

Improve this question

1 Answer 1

Reset to default
2

Actually, in worst case, none of your threads may be executing. Linux has plenty of its own threads that it also needs to schedule. You can always request to run multiple threads, but only by assigning a high priority to them can you hope to have them running simultaneously. No guarantees.

Assigning a core affinity to a thread is a bad idea. That could block your thread if another thread is already running on that core, and it does not relinquish. It's typically faster to use the next available core.

You may want to look at the "real-time" system calls in Linux, but Linux doesn't support "hard" real-time. Keep in mind that being too generous to your own threads might block some necessary Linux threads from running.

Improve this answer
3
  • My applications run on Linux. I think the existing scheduling scheme does not allow to fully exploit hardware multi-threading, or at least in the industrial development. Totally re-arranging the code to expose middle-high grain parallelism is sometimes unfeasible, makes code hard to understand and thus hard to maintain. Having threads co-executing in the same time makes possible to write a simpler parallelized code, in many cases with no risk of deadlocks and with no need of mutex/futex.
    – Alpa
    Commented Jul 20, 2016 at 7:29
  • But to have "threads co-executing in the same time" requires a core for each thread, and the current kernel certainly supports multi-threading in that form. You just need to trust the OS to schedule properly (with help from properly setting priorities). I have an application where "main" fires off three concurrent threads for a high-bandwidth application, and Linux has no trouble scheduling my threads such that no data is held-up.
    – Mark
    Commented Jul 20, 2016 at 7:39
  • If I understand well current Linux treats threads like independent units, which means it does not try to schedule them in the same time or on the same core (hyperthreading). So I can not trust a kernel, it does not know my intentions (I have no mean to declare them) and it does not try to be smart. In case of a fine-middle grain parallelism (which I'd like to exploit) this leads to a high overhead: cache misses, migration, mutual wait because one thread did not finish the task. Or may be I'm missing something important about the kernel.
    – Alpa
    Commented Jul 20, 2016 at 11:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.