2014-11-16 5 views
1

У меня есть несколько потоков, любой из этих потоков может писать строку, к которой обращается какой-либо другой поток.Чтение общего ресурса эффективно

Я не могу писать и читать в одно и то же время, но я не вижу причин, по которым я не могу дважды прочитать один и тот же ресурс из двух разных потоков.

Как разрешить асинхронное чтение строки, не позволяя асинхронной записи и чтения одновременно, на C++?

Я бы предположил, что я каким-то образом дожидаюсь права собственности на Mutex и каким-то образом позволяю другим операциям чтения знать, что собственный поток выполняет операцию чтения и не пишет операцию, поэтому он также может читать, но я могу «На самом деле я поставил простой флаг, говорящий« Я читаю »где-то, потому что, как только второе чтение игнорирует Mutex из-за флага, первая операция чтения завершится, и операция записи может произойти, пока выполняется вторая операция чтения ,

Я не уверен, что делать.

+0

Мое предположение, что вы хотите получить атомные обновления. Один из способов добиться этого - обеспечить потоки доступа к данным через указатель и иметь обновления, чтобы указатель указывал на другое местоположение. Таким образом, читатели никогда не увидели бы фрагмент данных в несогласованном состоянии (т. Е. Наполовину обновили). – didierc

ответ

1

Это называется The Readers-Writers Problem.

Я полагаю, что как только вы это узнаете, должно быть легко определить решения. Фактически, связанная статья представляет несколько из них.

semaphore wrt=1, mutex=1; 
readcount=0; 

writer() 
{ 
    wait(wrt); 
    // Writing is done 
    signal(wrt); 
} 

reader() 
{ 
    wait(mutex); 
     readcount++; 
     if (readcount == 1) 
      wait(wrt); 
    signal(mutex); 
    // Do the Reading 
    // (Critical Section Area) 
    wait(mutex); 
     readcount--; 
     if (readcount == 0) 
      signal(wrt); 
    signal(mutex); 
} 

Скопирован одно из решений для предотвращения (маловероятно) мёртвой ссылки

1

Посмотрите на boost::shared_mutex.

Класс boost :: shared_mutex обеспечивает реализацию мьютекса с несколькими считывателями/одиночными писателями.

+0

Я действительно не поклонник повышения, для меня это часто помогает сделать одну проблему немного легче - что не гарантирует размер библиотеки. – user1830431

1

Win32 API предоставляет «Slim Reader/Writer Lock» для этой ситуации. Они настроены и используются аналогично критическим разделам. Первый InitializeSRWLock используется для создания объекта блокировки. После этого поток только для чтения вызывает AcquireSRWLockShared перед доступом к общему ресурсу. Поток, который может изменить ресурс, вместо этого использует AcquireSRWLockExclusive. По завершении доступа к общему ресурсу блокировки освобождаются либо ReleaseSRWLockShared, либо ReleaseSRWLockExclusive.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa904937(v=vs.85).aspx

Смежные вопросы