[EMAIL PROTECTED] wrote on Tue, 20 Feb 2007 07:29 -0500: > dbpf-dspace.c:1371 > assert(!dbpf_op_queue_empty(dbpf_completion_queue_array[context_id])); > > According to the stack trace, this test() call followed a > trove_dspace_iterate_handles() call within the > trove_check_handle_ranges() function. This is part of the logic on > startup that scans all of the handles in the storage space to update the > list of available/used handles in trove-handle-mgmt.
Another thought for Sam, who knows this code better. (1) DBPF_COMPLETION_START modifies cur_op->op.state without holding the dbpf_completion_queue_array_mutex[cid] mutex. Then it grabs the mutex and puts the op on the completion array. (2) dbpf_dspace_test grabs that mutex, looks at op.state, then asserts that the queue must not be empty. Perhaps (1) modifies the state but doesn't get around to putting it on the completion array. (Possibly because the lock is held in (2).) Maybe (1) should put the op on the array before modifying its state, and hold the array mutex the whole time. I'm not sure what kind of locking rules are involved between the mutex in the op and the mutex on the completion array, though. Or what else might break with such a change. -- Pete _______________________________________________ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers