yamt commented on code in PR #15324:
URL: https://github.com/apache/nuttx/pull/15324#discussion_r1897078553
##########
sched/clock/clock_gettime.c:
##########
@@ -58,15 +58,15 @@ static clock_t clock_process_runtime(FAR struct tcb_s *tcb)
group = tcb->group;
- flags = spin_lock_irqsave(NULL);
+ flags = spin_lock_irqsave(&group->lock);
sq_for_every(&group->tg_members, curr)
{
tcb = container_of(curr, struct tcb_s, member);
runtime += tcb->run_time;
}
- spin_unlock_irqrestore(NULL, flags);
+ spin_unlock_irqrestore(&group->lock, flags);
Review Comment:
well, it depends on many parameters. how frequently cpus actually compete on
the specific lock(s) on a typical workload. what other data is on the cache
line. how the specific hardware implements cache coherency and locks. etc, etc.
it's far from obvious to me.
don't get me wrong. i'm not saying it isn't worth. it might be.
i'm just saying it might not be a good idea to go too further w/o a
benchmark.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
