Wayne Thornton commented on a discussion on cpukit/dhrl/dhrl.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_148384 > + return sc; > + } > + > + CPU_ZERO( &cpuset ); > + CPU_SET( core_a, &cpuset ); > + sc = rtems_task_set_affinity( > + dhrl_worker_a_id, > + sizeof( cpu_set_t ), > + &cpuset > + ); > + if ( sc != RTEMS_SUCCESSFUL ) { > + return sc; > + } > + > + // Initialize Worker B > + sc = rtems_task_create( @chris @joel Based on my understanding of the feedback and the self-contained objects documentation, the only hot path is when a user calls dhrl_fetch_data(), which locks and unlocks a mutex. If I use rtems_semaphore_obtain, I'll incur the overhead of the kernel looking up the rtems_id in a table every single time. By moving the mutex to a self-contained object rtems_mutex, I can remove that lookup overhead, making the hot path faster and more deterministic. The thread setup dhrl_init, on the other hand, is a cold path. It runs exactly once during system startup and the performance overhead of creating a task via the Classic API there doesn't matter. Based on that thinking, I'm considering continuing to use the Classic API (rtems_task_create and rtems_task_set_affinity) for the worker tasks and converting only the mutex to a self-contained object. Thoughts? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_148384 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
