Fixes the cache lock issue.

net/base/load_states_list.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // This is the list of load states and their values. For the enum values,
 // include the file "net/base/load_states.h".
 //
 // Here we define the values using a macro LOAD_STATE, so it can be
 // expanded differently in some places (for example, to automatically
 // map a load flag value to its symbolic name).
@@ skipping 21 matching lines @@
 
 // This state indicates that the URLRequest delegate has chosen to block this
 // request before it was sent over the network. When in this state, the
 // delegate should set a load state parameter on the URLRequest describing
 // the nature of the delay (i.e. "Waiting for <description given by
 // delegate>").
 LOAD_STATE(WAITING_FOR_DELEGATE, 4)
 
 // This state corresponds to a resource load that is blocked waiting for
 // access to a resource in the cache.  If multiple requests are made for the
-// same resource, the first request will be responsible for writing (or
-// updating) the cache entry and the second request will be deferred until
-// the first completes.  This may be done to optimize for cache reuse.
+// same resource, the requests eligible for shared writing among them will be

[jkarlin, 2017/02/03 18:26:19]

I don't know that we want to mention shared writers in this file, as it's a low
level detail.

Perhaps:

If multiple requests are made for the same resource, they'll typically run in
parallel but in some circumstances they may have to defer until a previous
request has completed.

[shivanisha, 2017/02/06 21:14:10]

Sounds good.

+// responsible for writing (or updating) the cache entry and the remaining
+// requests will be deferred until the writing completes.
 LOAD_STATE(WAITING_FOR_CACHE, 5)
 
 // This state corresponds to a resource load that is blocked waiting for
 // access to a resource in the AppCache.
 // Note: This is a layering violation, but being the only one it's not that
 // bad. TODO(rvargas): Reconsider what to do if we need to add more.
 LOAD_STATE(WAITING_FOR_APPCACHE, 6)
 
 // This state corresponds to a resource being blocked waiting for the
 // PAC script to be downloaded.
@@ skipping 38 matching lines @@
 // corresponds to the period after the request is sent and before all of the
 // response headers have been received.
 LOAD_STATE(WAITING_FOR_RESPONSE, 15)
 
 // This state corresponds to a resource load that is blocked waiting for a
 // read to complete.  In the case of a HTTP transaction, this corresponds to
 // the period after the response headers have been received and before all of
 // the response body has been downloaded.  (NOTE: This state only applies for
 // an URLRequest while there is an outstanding Read operation.)
 LOAD_STATE(READING_RESPONSE, 16)