MITHILESH MATTAPALLI commented on a discussion on cpukit/posix/src/aio_suspend.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/954#note_141999 > suspendcbp->requests_left++; > > } else { > + pthread_mutex_unlock( &aio_request_queue.mutex ); > pthread_mutex_lock( &request->suspendcbp->mutex ); You are absolutely right about the iteration safety dropping the lock inside the loop is unsafe because the queue could change while the lock is released. Thank you for catching that. To answer your question about the locking order: The deadlock (CID 1667285) arises from a 'Hold and Wait' on the same lock. aio_suspend holds aio_request_queue.mutex while waiting for a request to complete. However, the completion handler often needs to acquire that same aio_request_queue.mutex to remove the request from the queue. If aio_suspend waits while holding the lock, the handler blocks forever trying to acquire it. Since dropping the lock inside the loop is unsafe, would the correct approach be to restart the iteration from the beginning after we wake up and re-acquire the lock? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/954#note_141999 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
