GitLab

If the service has a matching port with a receive right in userspace,
the task with the receive right owns the lock. If the service is not
assigned, the lock is free.

This implementation polls to attempt to acquire the lock, using a
constant service name and constant polling interval. Further development
could fetch these values from another source of truth (a file of
constants, compiler macros, options loaded at runtime, etc.) or use
bootstrap_look_up and mach_port_request_notification to find the owner
of the lock and wait for the lock to be released.

This change includes two broad changes to preexisting unit tests, due
to issues revealed with those tests while developing this CL:

* app_server_unittest.cc included tests where the AppServer lived
  in the same scope as test code that generates a reference to the
  Global Prefs Object, which requires the prefs lock. This results in
  deadlock with a non-reentrant implementation of a prefs lock, since
  the AppServer owns that lock at that time. This CL introduces scopes
  to deallocate the AppServer instance before the test itself grabs
  the global prefs lock.
* prefs_unittest.cc marked out all the lock tests as Windows-only. Now
  that there is a Mac lock, this limitation does not need to exist.
  However, one of its tests explicitly checked that the lock supports
  reentrancy within a thread (while another verified that it bans
  reentrancy across threads). This test has been deleted, after
  discussion with teammates where we decided that a non-reentrant lock
  is desired.


Change-Id: I513cb67d1c3a12b2b0c01b532a9af10ae2233530
Bug: 1135692
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2453800Reviewed-by: Joshua Pawlicki <waffles@chromium.org>
Reviewed-by: Sorin Jianu <sorin@chromium.org>
Commit-Queue: Adam Norberg <norberg@google.com>
Cr-Commit-Position: refs/heads/master@{#815825}