Kinsey Moore commented on a discussion on cpukit/posix/src/aio_suspend.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/954#note_141723 > suspendcbp->requests_left++; > > } else { > + pthread_mutex_unlock( &aio_request_queue.mutex ); > pthread_mutex_lock( &request->suspendcbp->mutex ); Right, resolving a deadlock is typically accomplished by enforcing a strict locking order or a reduction in locking to avoid multiple locks being held at once. Where is the inverse of the locking order that requires this order to be switched/avoided? The queue is locked because this code is iterating over the items in the queue and this request code is inside the loop that is performing the iteration. It is most certainly not safe to unlock the queue while the iteration is occurring because a modification of the queue during iteration could result in unexpected behavior such as running over the end of the queue if an item is removed while the lock is dropped or missing an item if one is added while the lock is dropped. The validity of the request object is not in question as it is in the queue and cannot be removed while the queue is locked (assuming code elsewhere cannot destroy a request while it is still in the queue). -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/954#note_141723 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
