From d703e5451d1dc9edcc105a43011895d637f2df1f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Axel=20D=C3=B6rfler?= Date: Mon, 6 Jan 2003 08:08:13 +0000 Subject: [PATCH] Removed an XXX comment question, and replaced it with an explanation of the issue. git-svn-id: file:///srv/svn/repos/haiku/trunk/current@2363 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- src/kernel/core/scheduler.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/kernel/core/scheduler.c b/src/kernel/core/scheduler.c index 0e0421bb21..e0fd63a83f 100644 --- a/src/kernel/core/scheduler.c +++ b/src/kernel/core/scheduler.c @@ -47,8 +47,12 @@ dump_run_q(int argc, char **argv) } +/** Enqueues the thread to the run queue. + * Note: THREAD_LOCK must be held when entering this function + */ + void -thread_enqueue_run_q(struct thread *t) //XXX no locks? is this save? +thread_enqueue_run_q(struct thread *t) { struct thread *curr, *prev; @@ -93,7 +97,10 @@ thread_set_priority(thread_id id, int32 priority) if (t->id == id) { // it's ourself, so we know we aren't in the run queue, and we can manipulate // our structure directly - retval = t->priority; //XXX is this really save? can't we get preempted right here? + retval = t->priority; + // note that this might not return the correct value if we are preempted + // here, and another thread changes our priority before the next line is + // executed t->priority = priority; } else { int state = disable_interrupts();