Warum verwenden Android SystemProperties solche Speicherbarrieren?C++

Programme in C++. Entwicklerforum
Anonymous
 Warum verwenden Android SystemProperties solche Speicherbarrieren?

Post by Anonymous »

Ich habe die Implementierung der Systemeigenschaft von Android gelesen, und ich bin verwirrt, warum die Barrieren auf diese Weise verwendet werden. 731631F300090436D7F5DF80D50B6275C8C60A93.

Code: Select all

// The contract with readers is that whenever the dirty bit is set, an undamaged copy
// of the pre-dirty value is available in the dirty backup area. The fence ensures
// that we publish our dirty area update before allowing readers to see a
// dirty serial.
memcpy(pa->dirty_backup_area(), pi->value, old_len + 1);
if (have_override) {
memcpy(override_pa->dirty_backup_area(), override_pi->value, old_len + 1);
}
atomic_thread_fence(memory_order_release);
serial |= 1;
atomic_store_explicit(&pi->serial, serial, memory_order_relaxed);
strlcpy(pi->value, value, len + 1);
if (have_override) {
atomic_store_explicit(&override_pi->serial, serial, memory_order_relaxed);
strlcpy(override_pi->value, value, len + 1);
}
// Now the primary value property area is up-to-date. Let readers know that they should
// look at the property value instead of the backup area.
atomic_thread_fence(memory_order_release);
int new_serial = (len serial, new_serial, memory_order_relaxed);
Meine Frage ist: Nach Serial | = 1 , warum gibt es nichts, um atomic_store_explicit (& pi-> seriell, seriell, memory_order_relaxed) zu schützen, CODEL. Vor dem Lesen des schmutzigen Bits wie folgt: < /p>

Code: Select all

serial |= 1;
strlcpy(pi->value, value, len + 1);
atomic_store_explicit(&pi->serial, serial, memory_order_relaxed);
< /code>
Die Lesermethode: < /p>
uint32_t SystemProperties::ReadMutablePropertyValue(const prop_info* pi, char* value) {
// We assume the memcpy below gets serialized by the acquire fence.
uint32_t new_serial = load_const_atomic(&pi->serial, memory_order_acquire);
uint32_t serial;
unsigned int len;
for (;;) {
serial = new_serial;
len = SERIAL_VALUE_LEN(serial);
if (__predict_false(SERIAL_DIRTY(serial))) {
// See the comment in the prop_area constructor.
prop_area* pa = contexts_->GetPropAreaForName(pi->name);
memcpy(value, pa->dirty_backup_area(), len + 1);
} else {
memcpy(value, pi->value, len + 1);
}
atomic_thread_fence(memory_order_acquire);
new_serial = load_const_atomic(&pi->serial, memory_order_relaxed);
if (__predict_true(serial == new_serial)) {
break;
}
// We need another fence here because we want to ensure that the memcpy in the
// next iteration of the loop occurs after the load of new_serial above. We could
// get this guarantee by making the load_const_atomic of new_serial
// memory_order_acquire instead of memory_order_relaxed, but then we'd pay the
// penalty of the memory_order_acquire even in the overwhelmingly common case
// that the serial number didn't change.
atomic_thread_fence(memory_order_acquire);
}
return serial;
}

Quick Reply

Change Text Case: 
   
  • Similar Topics
    Replies
    Views
    Last post