Система Uptime & MemoryBarrier

Question

Мне нужен надежный способ получить бесперебойную работу системы и в конечном итоге использовать что-то следующее. Добавлены комментарии, чтобы помочь людям прочитать его. Я не могу использовать Task, поскольку это должно выполняться в приложении .NET 3.5.

// This is a structure, can't be marked as volatile 
// need to implement MemoryBarrier manually as appropriate 
private static TimeSpan _uptime; 

private static TimeSpan GetUptime() 
{ 
    // Try and set the Uptime using per counters 
    var uptimeThread = new Thread(GetPerformanceCounterUptime); 
    uptimeThread.Start(); 

    // If our thread hasn't finished in 5 seconds, perf counters are broken 
    if (!uptimeThread.Join(5 * 1000)) 
    { 
     // Kill the thread and use Environment.TickCount 
     uptimeThread.Abort(); 
     _uptime = TimeSpan.FromMilliseconds(
      Environment.TickCount & Int32.MaxValue); 
    } 

    Thread.MemoryBarrier(); 
    return _uptime; 
} 

// This sets the System uptime using the perf counters 
// this gives the best result but on a system with corrupt perf counters 
// it can freeze 
private static void GetPerformanceCounterUptime() 
{ 
    using (var uptime = new PerformanceCounter("System", "System Up Time")) 
    { 
     uptime.NextValue(); 
     _uptime = TimeSpan.FromSeconds(uptime.NextValue()); 
    } 
} 

Часть я борюсь с то, где должна быть размещена Thread.MemoryBarrier()? Я размещаю его перед чтением значения, но либо текущий поток, либо другой поток мог бы записать на него. Правильно ли это выглядит?

Edit, ответ, основанный на Daniel

Это то, что я eneded до реализации, спасибо вам обоим за понимание.

private static TimeSpan _uptime; 

private static TimeSpan GetUptime() 
{ 
    var uptimeThread = new Thread(GetPerformanceCounterUptime); 
    uptimeThread.Start(); 

    if (uptimeThread.Join(5*1000)) 
    { 
     return _uptime; 
    } 
    else 
    { 
     uptimeThread.Abort(); 
     return TimeSpan.FromMilliseconds(
      Environment.TickCount & Int32.MaxValue); 
    } 
} 

private static void GetPerformanceCounterUptime() 
{ 
    using (var uptime = new PerformanceCounter("System", "System Up Time")) 
    { 
     uptime.NextValue(); 
     _uptime = TimeSpan.FromSeconds(uptime.NextValue()); 
    } 
} 

Edit 2

обновляется на основе комментариев Боба.

private static DateTimeOffset _uptime; 

private static DateTimeOffset GetUptime() 
{ 
    var uptimeThread = new Thread(GetPerformanceCounterUptime); 
    uptimeThread.Start(); 

    if (uptimeThread.Join(5*1000)) 
    { 
     return _uptime; 
    } 
    else 
    { 
     uptimeThread.Abort(); 
     return DateTimeOffset.Now.Subtract(TimeSpan.FromMilliseconds(
      Environment.TickCount & Int32.MaxValue)); 
    } 
} 

private static void GetPerformanceCounterUptime() 
{ 
    if (_uptime != default(DateTimeOffset)) 
    { 
     return; 
    } 

    using (var uptime = new PerformanceCounter("System", "System Up Time")) 
    { 
     uptime.NextValue(); 
     _uptime = DateTimeOffset.Now.Subtract(
      TimeSpan.FromSeconds(uptime.NextValue())); 
    } 
} 

Answer 1

Thread.Join уже гарантирует, что записи, выполняемые uptimeThread видны в основном потоке. Вам не нужен явный барьер памяти. (без синхронизации, выполняемой Join, вам понадобятся барьеры на обоих потоках - после записи и перед чтением)

Однако существует потенциальная проблема с вашим кодом: запись в структуру TimeSpan не является атомарной, а основной поток и uptimeThread могут писать в это время одновременно (Thread.Abort просто сигнализирует об абортах, но не дожидается окончания прерывания потока), вызывая разрывную запись. Мое решение состояло бы в том, чтобы не использовать поле вообще при прерывании. Кроме того, множественные одновременные вызовы GetUptime() могут вызывать такую ​​же проблему, поэтому вместо этого вы должны использовать поле экземпляра.

private static TimeSpan GetUptime() 
{ 
    // Try and set the Uptime using per counters 
    var helper = new Helper(); 
    var uptimeThread = new Thread(helper.GetPerformanceCounterUptime); 
    uptimeThread.Start(); 

    // If our thread hasn't finished in 5 seconds, perf counters are broken 
    if (uptimeThread.Join(5 * 1000)) 
    { 
     return helper._uptime; 
    } else { 
     // Kill the thread and use Environment.TickCount 
     uptimeThread.Abort(); 
     return TimeSpan.FromMilliseconds(
      Environment.TickCount & Int32.MaxValue); 
    } 
} 

class Helper 
{ 
    internal TimeSpan _uptime; 

    // This sets the System uptime using the perf counters 
    // this gives the best result but on a system with corrupt perf counters 
    // it can freeze 
    internal void GetPerformanceCounterUptime() 
    { 
     using (var uptime = new PerformanceCounter("System", "System Up Time")) 
     { 
      uptime.NextValue(); 
      _uptime = TimeSpan.FromSeconds(uptime.NextValue()); 
     } 
    } 
} 

Однако, я не уверен, если отбрасывание счетчика производительности нить будет корректно работать на всех - Thread.Abort() только прекращает управляемое выполнение кода. Если код висит в вызове Windows API, поток будет продолжать работать.

Answer 2

AFAIK пишет, что в .NET неустойчивы, поэтому единственное место, где вам понадобится забор памяти, будет перед каждым чтением, поскольку они подлежат переупорядочению и/или кешированию. Цитирую a post by Joe Duffy:

Для справки, вот правила, как я пришел к пониманию их сказал так просто, как я могу:

Rule 1: Data dependence among loads and stores is never violated. 
Rule 2: All stores have release semantics, i.e. no load or store may move after one. 
Rule 3: All volatile loads are acquire, i.e. no load or store may move before one. 
Rule 4: No loads and stores may ever cross a full-barrier. 
Rule 5: Loads and stores to the heap may never be introduced. 
Rule 6: Loads and stores may only be deleted when coalescing adjacent loads and 
stores from/to the same location. 

Обратите внимание, что по этому определению, нелетучие нагрузки не требуются, чтобы имели какой-либо барьер, связанный с ними. Так что нагрузки могут быть свободно переупорядочены, и записи могут перемещаться после них (хотя и не раньше, из-за Правило 2). С этой моделью, единственным истинным случаем, когда вам действительно понадобится , сила полного барьера, предусмотренная Правилом 4, заключается в том, чтобы предотвратить переупорядочение в случае, когда за магазином следует летучая нагрузка. Без барьера инструкции могут быть изменены.