MITHILESH MATTAPALLI commented on a discussion on cpukit/posix/src/aio_suspend.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/954#note_141715 > suspendcbp->requests_left++; > > } else { > + pthread_mutex_unlock( &aio_request_queue.mutex ); > pthread_mutex_lock( &request->suspendcbp->mutex ); My reasoning for the locking order was to break the circular dependency that causes the deadlock (CID 1667285). As I understand it, the completion handler (ISR) needs the global aio_request_queue.mutex to finish processing the request. If we hold that queue lock here while waiting for the handler to finish, they end up waiting on each other. Regarding safety: I believe it is safe to drop the lock here because suspendcbp belongs to the current wait operation, so it should remain valid. Also, since POSIX rules state that the application must keep the aiocb valid while the operation is in progress, the request pointer should effectively be safe to access even if we briefly drop the global lock. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/954#note_141715 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
