| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This reverts commit de39d9242ae38733c33173957386db0b8060e52a.
Reason for revert: This revert is not needed
Change-Id: I34af8e5d75c724f6c4066fafbfc6bc7d58377601
|
| |
|
|
|
|
|
|
| |
This reverts commit 0cf90556de2bde53a1957c5946036b2fe2e4e429.
Reason for revert: Device boot failures - 144355953
Change-Id: Icd4fc8c7a1d06d688a6d37e6f1c1aa45563f711b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now, when we read a system property, we first (assuming we've
already looked up the property's prop_info) read the property's serial
number; if we find that the low bit (the dirty bit) in the serial
number is set, we futex-wait for that serial number to become
non-dirty. By doing so, we spare readers from seeing partially-updated
property values if they race with the property service's non-atomic
memcpy to the property value slot. (The futex-wait here isn't
essential to the algorithm: spinning while dirty would suffice,
although it'd be somewhat less efficient.)
The problem with this approach is that readers can wait on the
property service process, potentially causing delays due to scheduling
variance. Property reads are not guaranteed to complete in finite time
right now.
This change makes property reads wait-free and ensures that they
complete in finite time in all cases. In the new approach, we prevent
value tearing by backing up each property we're about to modify and
directing readers to the backup copy if they try to read a property
with the dirty bit set.
(The wait freedom is limited to the case of readers racing against
*one* property update. A writer can still delay readers by rapidly
updating a property --- but after this change, readers can't hang due
to PID 1 scheduling delays.)
I considered adding explicit atomic access to short property values,
but between binary compatibility with the existing property database
and the need to carefully handle transitions of property values
between "short" (compatible with atomics) and "long" (incompatible
with atomics) length domains, I figured the complexity wasn't worth it
and that making property reads wait-free would be adequate.
Test: boots
Bug: 143561649
Change-Id: Ifd3108aedba5a4b157b66af6ca0a4ed084bd5982
|
| |
|
|
|
| |
Test: n/a
Change-Id: Ieb5d18d479becb8c92cbf71a8bb7cd67f7c27dba
|
| |
|
|
|
|
|
|
|
|
|
| |
With the goal of disallowing exit time destructors, SystemProperties's
non-trivial destructor needs to be removed. This means replacing the
union hack with yet another hack as we don't want to allocate anything
despite relying on some polymorphism.
Bug: 73485611
Test: boot bullhead
Change-Id: I64223714c9b26c9724bfb8f3e2b0168e47b56bc8
|
|
|
Reinitializing system properties can result in crashes later in the
program, and is generally not recommended or even supported. This
change moves the actual logic for system properties into a class that
can be tested in isolation, without reinitializing the actual system
property area used in libc.
Bug: 62197783
Test: boot devices, ensure properties work
Test: system property unit tests and benchmarks
Change-Id: I9ae6e1b56c62f51a4d3fdb5b62b8926cef545649
|
