Linux multithreading-operating system thread synchronization mutex __linux

The main thing I think is the theory and the actual combination of methods to do, first of all, the theory of this piece in the operating system of the contents of the first statement. Then use the code under Linux to truly implement. Perterson Algorithm theory

The Perterson algorithm is used to realize mutually exclusive access to the critical area resources, and it is realized by the software mechanism. That is, in Linux system programming, how do you solve this problem if you don't want to use pthread_mutex_t mutex? The method of software implementation is given by Perterson algorithm. Pseudo Code

BOOL Flag[] = {false, false}; Flag[i] Indicates whether process I wants to enter the critical section, true indicates that you want to enter
int turn//turn = I, the process that can enter the critical section is I

void P0 () {while

    (true) {

        flag[0] = true; Oneself want to enter
        turn = 1;       However, courteous to each other while

        (Flag[1] && 1==turn),//At this time P1 execution conditions, let process 1 execution, process 0 busy waiting at this time

        *
         *critical region
         * *

        /flag[0] = False

    ;
}
void P1 () {while

    (true) {

        flag[1] = true;
        turn = 0;

        while (Flag[0] && 0==turn);
         /* *critical Region * * *

        /flag[1] = false;
    }

To analyze the above code, if because turn as a public resource, and it does not lock the province, so there must be a later access to its process, the assumption is P1. That is P0 first visit, P1 followed by the visit, that is, in fact, they both want to visit. But P0 than P1 a little faster, at this time P0 came in, first said they want to enter the critical area, and then let each other advanced turn=1. P1 than P0 slow, at this time P1 also want to enter, then flag[1]=true; Turn=0 note, before turn=0, because P0 first executed, so P0 has been busy waiting, at this time turn=0, P0 into the critical area, because turn save is a late assignment, so, if turn=0. Indicates that P1 is backward, then P0 advanced to execute it.

If there is no need to enter the situation, it is simple. Producer-Consumer issues theory

This piece, mainly refers to the undergraduate course of the operating system textbook. The specific content is not much said, give the pseudocode I feel already very clear.

Add: In this way, there is a problem when writing code in real time. Although producers and consumers are accessing different units, the operation of queues. Producers and consumers may have problems. Must be good to analyze the problem clearly, whether this is the reader-writer problem. No... Because, the access is not the same unit.

New Understanding
Previously on the above issues do not know thoroughly, in fact, I have recently written in Linux under the code is not a producer-consumers. Nor is it reader-writer. It is two write, that lock to control mutual exclusion, signal control synchronization can be.
However, the above code, I have analyzed clearly. is not a reader-writer, because the access is not the same variable. There was no contradiction in reading-writing.

The problem above is the classic producer-consumer problem. But my question is, what is your mutex for?
Now think clearly, is added to the entire queue above.
Because I didn't understand that before, I think if it is a single producer and a single consumer, there is no need for a mutex because the nature of the producer and the consumer does not have access to the same variable. So, there is only the semantics of synchronization between them. The semantics of mutual exclusion are added between producers and producers, consumers and consumers. It is not wrong to think so, because different producers have to apply for a unit and two producers cannot apply for the same unit. So, they need to be mutually exclusive. Consumers are similarly.

So, I thought that the difference between individual producers and multiple consumers of a single producer was that there was no lock between the same objects. But now, the idea is wrong. In fact, basically there is no problem.

Consider this scenario: for a queue, there is a producer, there is a consumer. OK, now, there's only one element in the queue.

At the same time, producers and consumers, note that the queue is assumed to be implemented with a linked list. At this point, there is only one element in the queue. The pointer to the current node is P, and for the producer, it appends an element to the P and the consumer releases p. At this point, two code is executed, assuming the consumer is slightly faster than the producer, releasing P. And at this time the producer because has passed to judge whether the queue is empty situation, still executes p->next = q; Then, obviously, the program will go wrong.
That's the problem, at least that's what I think. For producers and consumers, a lock is added to the queue. This lock avoids requesting resources for the same class of objects, as well as avoiding changes to queues for different objects. However, this will also bring problems, that is, production can not be consumed when consumption can not produce. Logically, the logic of their two is not related. Philosophical Dining Problems Reader-writer question

Question Description: Reader-writer is such a problem. Allows multiple threads to read at the same time, but, however, only one thread is allowed to write. That is, if a thread is writing, then other threads cannot write or read. However, if a thread is reading, other threads can read, but not write.

Problem analysis: Consider the reader-writer with mutually exclusive implementation, so as to avoid the reader-writer mutual exclusion. At this time, read the time can not write, write when you can not read. However, doing so will lead to the inability to read when reading. So, that's the problem. There is also a need to achieve a certain degree of sharing between readers.

At this point, you can consider to the reader a counter, when this counter is not 0, other readers only need to modify the value of the counter, and then read it. There is no need to wait for the lock between the reader and the writer. Then the read operation is complete, and the value of the counter can be modified. When the counter value is 0, the request and release are required. Obviously, different readers are shared with this counter, so they also need mutually exclusive access.

semaphore_t Rmutex = 1; semaphore_t Wmutex = 1;
    void Reader () {P (Rmutex);
    if (Readcount = = 0) P (Wmutex);
    readcount++;

    V (Rmutex);
    /* Read operation * P (RMUTEX);
    readcount--;
    if (Readcount = = 0) V (Wmutex);

V (Rmutex);
    } void writer () {P (Wmutex);
/* Write operation */V (WMUTEX); }