Spin locks, mutexes, semaphores, etc., when the ABCD four thread waiting for locks S at the same time, when the lock is released, S thread ABCD who can obtain the lock S, assuming the ABCD according to the order issued for the lock S?
If Linux c now there is no guarantee that according to the order for locks, in extreme cases, ACD can always get a lock, and always get less than B, that is not a bug?

CodePudding user response:

Looks like BBS lack of speech master ah,,,

CodePudding user response:

Mutexes and semaphores unlikely situation, post code and test the proposed methods, the spin lock it is possible,

CodePudding user response:

How fair lock, are they not see the CPU scheduling

CodePudding user response:

This just shows you design is a problem with the thread, the same priority cases, the probability of each thread execution should be equal, there is no have no thread of execution, unless the ACD priority is higher than B, and there is no delay in ACD thread, will lead to B is not perform,

CodePudding user response:

Linux is actually may be at risk for this kind of situation, only that the ABCD equilibrium to acquiring a lock, there is a person for a long time to get less than the probability is low,

CodePudding user response:

Is that there may be ah, but why don't you go to circumvent off? And probability is low, and, moreover, there are four threads to wait for a lock, so if we can consider itself, this is a design flaw, 2 as far as possible, less and less and less for digging holes and big brother

CodePudding user response:

Judgment so design must add a scheduling priority as if they take turns to take the lock is not the same as the priority according to the figure from a few if the else

CodePudding user response:

This is the so-called "fairness" problem, specific situation to look at the implementation of the lock, if using FIFO scheduling, thread starvation will not happen,