commit e270ce5d08b9aaba5d3821a6d600fa74eb3724f8
author Etienne Bergeron <etienneb@chromium.org> Tue Aug 10 16:43:06 2021
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Aug 10 16:43:06 2021
tree b6fee82521585a3e7633443d75d75f486cc4d2b0
parent ea30055b4d7177e457622cad77acc5d89eafecf3

Fix priority inversion with protobufs initialization on Windows

This CL is fixing a priority inversion caused by process-wide lock used
to guard recursive protobufs initialization.

Protobuf are lazily initialized and inner protobufs are recursively
initialized at that same time. To avoid conflicts (parallel loading)
a lock is used to ensure only one thread is currently loading some
protobufs definition.

The priority inversion is caused when a background thread is creating
a protobuf and needs to load it. Any attempt to initialize a other
protobuf (even not related) will be blocked until the completion of
the background loading.

This CL is proposing to boost thread priority while loading protobuf.
Since protobuf are lazily loaded, they can only be loaded once.


Example:
  68fee496149cd484

Main Thread:
  NtWaitForAlertByThreadId
  RtlAcquireSRWLockExclusive
  google::protobuf::internal::InitSCCImpl
  autofill::AutofillPageQueryRequest::AutofillPageQueryRequest

Background Thread:
  InitDefaultsscc_info_VisualFeatures_ColorHistogramBin_components_2fsafe_5fbrowsing_2fcore_2fproto_2fcsd_2eproto
  [...]
  google::protobuf::internal::`anonymous namespace'::InitSCC_DFS
  google::protobuf::internal::InitSCCImpl
  safe_browsing::ClientSideModel::ClientSideModel


Bug: 1218253
Change-Id: I145cf2087bc2189ec14998ec594b4042c0a09cc2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3076381
Commit-Queue: Etienne Bergeron <etienneb@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/master@{#910346}