I am afraid the race is (may be one of) the root cause of TS-857, but I am not sure.
On Wed, 2012-03-21 at 14:53 +0000, John Plevyak (Commented) (JIRA) wrote: > [ > https://issues.apache.org/jira/browse/TS-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13234393#comment-13234393 > ] > > John Plevyak commented on TS-1158: > ---------------------------------- > > The mutex switch occurs in the HttpSessionManager. When a session is passed > to it, the read.vio.mutex and write.vio.mutex from the old controlling HttpSM > are replaced with that of a hash bucket of sessions in the Manager (a hash to > reduce contention on this globally shared data structure). When a session is > requested from the HttpSessionManager, they are replaced with those of the > new HttpSM which will be using that OS connection. During the swap, the > previous and new mutexes are held, but nevertheless, a race is possible if a > thread grabs the old (pre substitution) mutex, then a context switch occurs > and the mutexes are swapped and the old mutex (pre substitute) lock is > released, then the first thread resumes, locks the (pre substitution) mutex > and now two threads are running while thinking they are holding the mutex for > the NetVC. The solution is to ensure, after the lock has been taken, that > the mutex we have locked is the same one that is protecting the NetVC. If it > is not, we back out and retry later. > > > Race on mutex switching for NetVConnections in UnixNetVConnection::mainEvent > > ---------------------------------------------------------------------------- > > > > Key: TS-1158 > > URL: https://issues.apache.org/jira/browse/TS-1158 > > Project: Traffic Server > > Issue Type: Bug > > Components: Core > > Affects Versions: 3.0.3 > > Environment: ALL > > Reporter: John Plevyak > > Assignee: John Plevyak > > Fix For: 3.1.4 > > > > Attachments: ts-1158-jp1.patch > > > > > > Because of the way session management works, the vio.mutex must be > > re-verified to be identical to the one the lock was taken on after the lock > > is acquired. Otherwise there is a race when the mutex is switched allowing > > such that the old lock is held while the new lock is in not held. > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators: > https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > >
