Speculatively use memory barriers for loading and storing g_context,

Speculatively use memory barriers for loading and storing g_context,
which points to a data structure that might otherwise not be fetched
together with the pointer.

BUG=NONE
R=rogerta@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=277418

[Alexander Potapenko, 2014-06-10 11:39:08]

Roger, can you please take a look?
I've found this by manual code inspection - aren't there any tests that run this
code from several threads?

[Roger Tawa OOO till Jul 10th, 2014-06-10 15:57:54]

Thanks for taking the time to fix Alexander!

Can you explain further the scenario that would cause the old code to fail but
not the new code?

I guess there aren't any multi-threaded RLZ tests.  Maybe you could add one at
the same time where the NoBarrier code would fail the new code would not?

[Alexander Potapenko, 2014-06-11 15:00:48]

On 2014/06/10 15:57:54, Roger Tawa wrote:
> Thanks for taking the time to fix Alexander!
> 
> Can you explain further the scenario that would cause the old code to fail but
> not the new code?
I'm not really familiar with this code, but according to the comment at line
184, g_context can be accessed and modified by several threads.
I suppose this happens during the following scenario:
1. Thread 1 sets up a URLRequestContextGetter by writing some values to the
corresponding memory location.
2. Thread 1 writes the pointer to the context into g_context.
3. Thread 2 reads the pointer from g_context into a local variable.
4. Thread 2 dereferences the pointer and reads the data from
URLRequestContextGetter.

On modern processors steps 1 and 2 and 3 and 4 aren't guaranteed to happen in
exactly this order (even if the instructions aren't reordered by the compiler,
the memory accesses can be reordered by the CPU). To ensure the mutual order of
those steps you generally need to issue a memory barrier between them.
Currently the following ordering is possible even on x86: 2-3-4-1, i.e. the
second thread may read an old value.

> I guess there aren't any multi-threaded RLZ tests.  Maybe you could add one at
> the same time where the NoBarrier code would fail the new code would not?
I'll take a look at the existing tests, but it's nearly impossible to trigger
the case I've described on x86.
ThreadSanitizer could've spotted this problem, however.

[Roger Tawa OOO till Jul 10th, 2014-06-13 13:47:53]

lgtm

[Alexander Potapenko, 2014-06-16 11:50:59]

The CQ bit was checked by glider@chromium.org

[commit-bot: I haz the power, 2014-06-16 11:51:44]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/glider@chromium.org/327783003/1

[commit-bot: I haz the power, 2014-06-16 13:56:09]

Change committed as 277418