Мьютекс пример / учебник?

хотя мьютекс может использоваться для решения других проблем, основная причина их существования заключается в обеспечении взаимного исключения и тем самым решении того, что известно как состояние расы. Когда два (или более) потока или процесса пытаются получить доступ к одной и той же переменной одновременно, у нас есть потенциал для состояния гонки. Рассмотрим следующий код

//somewhere long ago, we have i declared as int
void my_concurrently_called_function()
{
  i++;
}

схематично это выглядит так просто. Это всего лишь одно утверждение. Однако типичный эквивалент языка псевдо-ассемблера может быть:

load i from memory into a register
add 1 to i
store i back into memory

поскольку все эквивалентные инструкции на языке ассемблера требуются для выполнения операции приращения на i, мы говорим, что приращение i является неатмоической операцией. Атомарная операция-это операция, которая может быть выполнена на аппаратном обеспечении с гарантией того, что она не будет прервана после начала выполнения инструкции. Приращение i состоит из цепочки из 3 атомарных инструкций. В параллельной системе, где несколько потоков вызывают функцию, возникают проблемы когда поток читает или пишет в неправильное время. Представьте, что у нас есть два потока, работающие одновременно, и один вызывает функцию сразу после другого. Давайте также скажем, что мы инициализировали до 0. Также предположим, что у нас есть много регистров и что два потока используют совершенно разные регистры, поэтому коллизий не будет. Фактическое время этих событий может быть:

thread 1 load 0 into register from memory corresponding to i //register is currently 0
thread 1 add 1 to a register //register is now 1, but not memory is 0
thread 2 load 0 into register from memory corresponding to i
thread 2 add 1 to a register //register is now 1, but not memory is 0
thread 1 write register to memory //memory is now 1
thread 2 write register to memory //memory is now 1

что случилось, так это то, что у нас есть два потока, увеличивающие i одновременно, наши функция вызывается дважды, но результат не соответствует этому факту. Похоже, что функция была вызвана только один раз. Это происходит потому, что атомарность "сломана" на машинном уровне, то есть потоки могут прерывать друг друга или работать вместе в неправильное время.

нам нужен механизм, чтобы решить эту. Нам нужно наложить некоторый порядок на инструкции выше. Один общий механизм-блокировать все потоки, кроме одного. Мьютекс Pthread использует этот механизм.

какие-нить который должен выполнить некоторые строки кода, которые могут небезопасно изменять общие значения другими потоками в то же время (используя телефон, чтобы поговорить с женой), сначала должен быть сделан получить блокировку на мьютексе. Таким образом, любой поток, требующий доступа к общим данным, должен проходить через блокировку мьютекса. Только тогда поток сможет выполнить код. Этот раздел кода называется критическим разделом.

как только поток выполнил критический раздел, он должен освободить блокировку на мьютексе, чтобы другой поток мог получить блокировку на мьютексе.

концепция наличия мьютекса кажется немного странной при рассмотрении людей, ищущих эксклюзивный доступ к реальным физическим объектам, но при программировании мы должны быть преднамеренными. Параллельные потоки и процессы не имеют социального и культурного воспитания, которое мы делаем, поэтому мы должны заставить их делиться данными красиво.

Итак, технически говоря, как работает мьютекс? Разве он не страдает от той же расы условия, о которых мы говорили ранее? Разве pthread_mutex_lock () не немного сложнее, чем простое приращение переменной?

Технически говоря, нам нужна аппаратная поддержка, чтобы помочь нам. Разработчики оборудования дают нам машинные инструкции, которые делают больше, чем одну вещь, но гарантированно являются атомарными. Классическим примером такой инструкции является test-and-set (TAS). При попытке получить блокировку ресурса мы можем использовать TAS, чтобы проверить, является ли значение в памяти 0. Если это так, то это будет наш сигнал, что ресурс используется, и мы ничего не делаем (или, точнее, мы ждем по какому-то механизму. Мьютекс pthreads помещает нас в специальную очередь в операционной системе и уведомляет нас, когда ресурс становится доступным. Более тупые системы могут потребовать от нас сделать плотную петлю вращения, проверяя условие снова и снова). Если значение в памяти не равно 0, TAS устанавливает местоположение на что-то отличное от 0 без использования каких-либо других инструкций. Это как объединение две инструкции по сборке в 1, чтобы дать нам атомарность. Таким образом, тестирование и изменение значения (если изменение уместно) не может быть прервано после его начала. Мы можем построить мьютексы поверх такой инструкции.

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

лучшие темы учебник я знаю-это здесь:

https://computing.llnl.gov/tutorials/pthreads/

Мне нравится, что это написано об API, а не о конкретной реализации, и это дает некоторые хорошие простые примеры, чтобы помочь вам понять синхронизацию.

Я недавно наткнулся на этот пост и думаю, что ему нужно обновленное решение для мьютекса стандартной библиотеки c++11 (а именно std::mutex).

я вставил код ниже (мои первые шаги с мьютексом - я узнал параллелизм на win32 с HANDLE, SetEvent, WaitForMultipleObjects и т. д.).

Так как это моя первая попытка с std::mutex и друзьями, я хотел бы видеть комментарии, предложения и улучшения!

#include <condition_variable>
#include <mutex>
#include <algorithm>
#include <thread>
#include <queue>
#include <chrono>
#include <iostream>


int _tmain(int argc, _TCHAR* argv[])
{   
    // these vars are shared among the following threads
    std::queue<unsigned int>    nNumbers;

    std::mutex                  mtxQueue;
    std::condition_variable     cvQueue;
    bool                        m_bQueueLocked = false;

    std::mutex                  mtxQuit;
    std::condition_variable     cvQuit;
    bool                        m_bQuit = false;


    std::thread thrQuit(
        [&]()
        {
            using namespace std;            

            this_thread::sleep_for(chrono::seconds(5));

            // set event by setting the bool variable to true
            // then notifying via the condition variable
            m_bQuit = true;
            cvQuit.notify_all();
        }
    );


    std::thread thrProducer(
        [&]()
        {
            using namespace std;

            int nNum = 13;
            unique_lock<mutex> lock( mtxQuit );

            while ( ! m_bQuit )
            {
                while( cvQuit.wait_for( lock, chrono::milliseconds(75) ) == cv_status::timeout )
                {
                    nNum = nNum + 13 / 2;

                    unique_lock<mutex> qLock(mtxQueue);
                    cout << "Produced: " << nNum << "\n";
                    nNumbers.push( nNum );
                }
            }
        }   
    );

    std::thread thrConsumer(
        [&]()
        {
            using namespace std;
            unique_lock<mutex> lock(mtxQuit);

            while( cvQuit.wait_for(lock, chrono::milliseconds(150)) == cv_status::timeout )
            {
                unique_lock<mutex> qLock(mtxQueue);
                if( nNumbers.size() > 0 )
                {
                    cout << "Consumed: " << nNumbers.front() << "\n";
                    nNumbers.pop();
                }               
            }
        }
    );

    thrQuit.join();
    thrProducer.join();
    thrConsumer.join();

    return 0;
}

функции pthread_mutex_lock() или приобретает мьютекс для вызывающего потока или блокирует поток до тех пор, пока мьютекс не будет получен. Связанные pthread_mutex_unlock() освободит мьютекс.

думаю мьютекса как очередь, каждый поток, который пытается получить мьютекс будет помещен в конец очереди. Когда поток освобождает мьютекс, следующий поток в очереди и сейчас работает.

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

вы должны проверить мьютекс перед использованием переменной, защищенной мьютексом. Таким образом, ваш pthread_mutex_lock() может (в зависимости от реализации) дождаться освобождения mutex1 или вернуть значение, указывающее, что блокировка не может быть получена, если кто-то уже заблокировал ее.

мьютекс на самом деле просто упрощенный семафора. Если Вы читаете о них и понимаете их, вы понимаете мьютексы. Есть несколько вопросов, касающихся мьютексов и семафоров в SO. разница между двоичным семафором и мьютексом,когда мы должны использовать мьютекс и когда мы должны использовать семафор и так далее. В туалет например в первой ссылке есть хороший пример, как можно подумать. Все, что делает код, это проверить, доступен ли ключ, и если он есть, резервирует его. Обратите внимание, что вы на самом деле не зарезервировать сам туалет, но ключ.

СЕМАФОР ПРИМЕР:

sem_t m;
sem_init(&m, 0, 0); // initialize semaphore to 0

sem_wait(&m);
// critical section here
sem_post(&m);

Ссылка : http://pages.cs.wisc.edu/~remzi/Classes/537/Fall2008/Notes/threads-semaphores.txt

для тех, кто ищет пример мьютекса shortex:

#include <mutex>
using namespace std;

int main() {
    mutex m;

    m.lock();
    // do thread-safe stuff
    m.unlock();

    return 0;
}