Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ThreadOptions is not fully used while creating new kernel thread #790

Closed
Tracked by #889
jellllly420 opened this issue Apr 25, 2024 · 1 comment · Fixed by #782
Closed
Tracked by #889

ThreadOptions is not fully used while creating new kernel thread #790

jellllly420 opened this issue Apr 25, 2024 · 1 comment · Fixed by #782

Comments

@jellllly420
Copy link
Contributor

Here is the aster-nix::thread::kernel_thread::ThreadOptions.

/// Options to create or spawn a new thread.
pub struct ThreadOptions {
    func: Option<Box<dyn Fn() + Send + Sync>>,
    priority: Priority,
    cpu_affinity: CpuSet,
}

It has fields representing priority and cpu affinity. But when we create new kernel thread in the code below,

fn new_kernel_thread(mut thread_options: ThreadOptions) -> Arc<Self> {
        let task_fn = thread_options.take_func();
        let thread_fn = move || {
            task_fn();
            let current_thread = current_thread!();
            // ensure the thread is exit
            current_thread.exit();
        };
        let tid = allocate_tid();
        let thread = Arc::new_cyclic(|thread_ref| {
            let weal_thread = thread_ref.clone();
            let task = TaskOptions::new(thread_fn)
                .data(weal_thread)
                .build()
                .unwrap();
            let status = ThreadStatus::Init;
            let kernel_thread = KernelThread;
            Thread::new(tid, task, kernel_thread, status)
        });
        thread_table::add_thread(thread.clone());
        thread
    }

we never use this two fields to construct TaskOptions, therefore the bound task is always of default configuration.

One problem caused by this issue is that all Workers in WORKERPOOL_HIGH_PRI are of normal priority instead of real-time priority, which is incorrect and can cause starvation in some specific cases.

@tatetian
Copy link
Contributor

@jellllly420 Good job on spotting the bug. Could you try to fix it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants