关于操作系统:二进制信号量和互斥量之间的区别

Difference between binary semaphore and mutex

二进制信号量和互斥量之间是否存在差异,或它们基本相同?


它们不是同一件事。它们用于不同的目的!
虽然两种类型的信号量都具有完整/空状态并使用相同的API,但它们的使用方式却大不相同。

互斥信号量
互斥信号量用于保护共享资源(数据结构,文件等)。

Mutex信号量由接受它的任务"拥有"。如果任务B尝试semGive当前由任务A持有的互斥锁,则任务B的调用将返回错误并失败。

互斥锁始终使用以下顺序:

1
2
3
  - SemTake
  - Critical Section
  - SemGive

这是一个简单的例子:

1
2
3
4
5
6
7
8
  Thread A                     Thread B
   Take Mutex
     access data
     ...                        Take Mutex  <== Will block
     ...
   Give Mutex                     access data  <== Unblocks
                                  ...
                                Give Mutex

二进制信号量
Binary Semaphore解决了一个完全不同的问题:

  • 任务B等待发生某事(例如传感器被绊倒)。
  • 传感器跳闸和中断服务程序运行。它需要通知行程的任务。
  • 任务B应该运行并对传感器跳闸采取适当的措施。然后回去等。
1
2
3
4
   Task A                      Task B
   ...                         Take BinSemaphore   <== wait for something
   Do Something Noteworthy
   Give BinSemaphore           do something    <== unblocks

请注意,对于二进制信号量,B可以使用信号量和A来提供它。
同样,二进制信号量不保护资源不被访问。给予和获取信号量的行为从根本上是分离的。
对于相同的任务而言,通常对于给予和获取相同的二进制信号量没有多大意义。


厕所的例子是一个令人愉快的比喻:

Mutex:

Is a key to a toilet. One person can
have the key - occupy the toilet - at
the time. When finished, the person
gives (frees) the key to the next
person in the queue.

Officially:"Mutexes are typically
used to serialise access to a section
of re-entrant code that cannot be
executed concurrently by more than one
thread. A mutex object only allows one
thread into a controlled section,
forcing other threads which attempt to
gain access to that section to wait
until the first thread has exited from
that section." Ref: Symbian Developer
Library

(A mutex is really a semaphore with
value 1.)

Semaphore:

Is the number of free identical toilet
keys. Example, say we have four
toilets with identical locks and keys.
The semaphore count - the count of
keys - is set to 4 at beginning (all
four toilets are free), then the count
value is decremented as people are
coming in. If all toilets are full,
ie. there are no free keys left, the
semaphore count is 0. Now, when eq.
one person leaves the toilet,
semaphore is increased to 1 (one free
key), and given to the next person in
the queue.

Officially:"A semaphore restricts the
number of simultaneous users of a
shared resource up to a maximum
number. Threads can request access to
the resource (decrementing the
semaphore), and can signal that they
have finished using the resource
(incrementing the semaphore)." Ref:
Symbian Developer Library


Mutex只能由获取它的线程释放,而您可以从任何其他线程(或进程)发出信号量信号,因此信号量更适合某些同步问题,如producer-consumer。

在Windows上,二进制信号量更像是事件对象而不是互斥体。


关于这个主题的好文章:

  • MUTEX VS. SEMAPHORES - 第1部分:SEMAPHORES
  • MUTEX VS. SEMAPHORES - 第2部分:MUTEX
  • MUTEX VS. SEMAPHORES - 第3部分(最后部分):相互排除问题

从第2部分:

The mutex is similar to the principles
of the binary semaphore with one
significant difference: the principle
of ownership. Ownership is the simple
concept that when a task locks
(acquires) a mutex only it can unlock
(release) it. If a task tries to
unlock a mutex it hasn’t locked (thus
doesn’t own) then an error condition
is encountered and, most importantly,
the mutex is not unlocked. If the
mutual exclusion object doesn't have
ownership then, irrelevant of what it
is called, it is not a mutex.


由于上述答案都没有解决这个混乱,所以这里有一个让我感到困惑的答案。

Strictly speaking, a mutex is a locking mechanism used to
synchronize access to a resource. Only one task (can be a thread or
process based on OS abstraction) can acquire the mutex. It means there
will be ownership associated with mutex, and only the owner can
release the lock (mutex).

Semaphore is signaling mechanism ("I am done, you can carry on" kind of signal). For example, if you are listening songs (assume it as
one task) on your mobile and at the same time your friend called you,
an interrupt will be triggered upon which an interrupt service routine
(ISR) will signal the call processing task to wakeup.

资料来源:http://www.geeksforgeeks.org/mutex-vs-semaphore/


它们的同步语义非常不同:

  • 互斥体允许序列化对给定资源的访问,即多个线程一次一个地等待锁定,如前所述,线程拥有锁定直到完成:只有这个特定的线程可以解锁它。
  • 二进制信号量是一个值为0和1的计数器:一个任务阻塞它,直到任何任务执行sem_post。信号量通告资源可用,并提供等待信号可用的机制。

因此,可以看到互斥体作为从任务传递到任务的令牌和信号量作为流量红灯(它向某人发出信号,表明它可以继续)。


  • 根据定义,Mutex用于序列化对一部分无法同时执行的可重入代码的访问。
    多个线程。

  • 根据定义,信号量将共享资源的并发用户数限制为a
    最大数量

  • 信号量可以是互斥量,但互斥量永远不会是信号量。这只是意味着二进制信号量可以用作Mutex,但是Mutex永远不会展示信号量的功能。

  • 信号量和Mutex(至少是最新的内核)本质上都是非递归的。
  • 没有人拥有信号量,而Mutex是拥有的,所有者对它们负责。这很重要
    区别于调试的角度。
  • 在Mutex的情况下,拥有Mutex的线程负责释放它。但是,在信号量的情况下,这个
    条件不是必需的。任何其他线程都可以通过使用s m p s(function.e_ot)发信号来释放信号量

  • 另一个对开发人员很重要的区别是,信号量是系统范围的,并且保持文件形式
    文件系统,除非另有清理。 Mutex是进程范围的,并在进程退出时自动清理。

  • 信号量的本质使得它们可以用于同步相关和不相关的过程,以及它们之间
    线程。 Mutex只能用于线程之间的同步,最多只能用于相关进程(pthread)
    最新内核的实现附带了一个允许在相关进程之间使用Mutex的功能。
  • 根据内核文档,与信号量相比,Mutex更轻。这意味着一个程序
    与具有Mutex的程序相比,信号量使用具有更高的内存占用。
  • 从使用角度来看,与信号量相比,Mutex具有更简单的语义。


在理论层面,它们在语义上没有区别。您可以使用信号量实现互斥锁,反之亦然(请参阅此处的示例)。在实践中,实施是不同的,它们提供略有不同的服务。

实际差异(就其周围的系统服务而言)是互斥体的实现旨在成为更轻量级的同步机制。在oracle中,互斥体被称为锁存器,信号量被称为等待。

在最低级别,他们使用某种原子测试和设置机制。这将读取内存位置的当前值,计算某种条件,并在单个指令中的该位置写出一个无法中断的值。这意味着您可以获取互斥锁并进行测试以查看是否有其他人在您之前拥有它。

典型的互斥实现有一个进程或线程执行测试和设置指令,并评估是否有其他设置互斥锁。这里的一个关键点是没有与调度程序的交互,因此我们不知道(并且不关心)谁设置了锁。然后我们要么放弃我们的时间片,并在重新安排任务时再次尝试它,或者执行自旋锁。自旋锁是一种算法,如:

1
2
3
4
5
Count down from 5000:
     i. Execute the test-and-set instruction
    ii. If the mutex is clear, we have acquired it in the previous instruction
        so we can exit the loop
   iii. When we get to zero, give up our time slice.

当我们完成执行受保护的代码(称为临界区)时,我们只需将互斥量值设置为零或任何"清除"的方式。如果多个任务正在尝试获取互斥锁,则在释放互斥锁后恰好安排的下一个任务将获得对该资源的访问权限。通常,您将使用互斥锁来控制同步资源,其中仅在非常短的时间段内需要独占访问,通常是为了更新共享数据结构。

信号量是一种同步数据结构(通常使用互斥锁),它具有计数和一些系统调用包装,它们与调度程序交互的程度比互斥库更深。信号量递增和递减,用于阻止任务,直到其他东西准备好。有关此的简单示例,请参阅生产者/消费者问题。信号量初始化为某个值 - 二进制信号量只是信号量初始化为1的特殊情况。发布信号量可以唤醒等待进程。

基本信号量算法如下所示:

1
2
3
4
5
6
7
8
9
10
11
(somewhere in the program startup)
Initialise the semaphore to its start-up value.

Acquiring a semaphore
   i. (synchronised) Attempt to decrement the semaphore value
  ii. If the value would be less than zero, put the task on the tail of the list of tasks waiting on the semaphore and give up the time slice.

Posting a semaphore
   i. (synchronised) Increment the semaphore value
  ii. If the value is greater or equal to the amount requested in the post at the front of the queue, take that task off the queue and make it runnable.  
 iii. Repeat (ii) for all tasks until the posted value is exhausted or there are no more tasks waiting.

在二进制信号量的情况下,两者之间的主要实际差异是围绕实际数据结构的系统服务的性质。

编辑:正如埃文正确指出的那样,自旋锁将减慢单处理器机器的速度。您只能在多处理器盒上使用自旋锁,因为在单个处理器上,当另一个任务正在运行时,持有互斥锁的进程将永远不会重置它。自旋锁只适用于多处理器架构。


虽然互斥和信号量被用作同步原语,但它们之间存在很大差异。
在互斥锁的情况下,只有锁定或获取互斥锁的线程才能解锁它。
在信号量的情况下,等待信号量的线程可以由不同的线程发信号通知。
某些操作系统支持在进程之间使用互斥锁和信号量。通常用法是在共享内存中创建。


Mutex:假设我们有关键部分线程T1想要访问它,然后它遵循以下步骤。
T1:

  • 使用关键部分
  • 开锁
  • 二进制信号量:它基于信令等待和信号工作。
    等待(s)将"s"值减少一个通常"s"值初始化为值"1",
    signal(s)将"s"值增加1。如果"s"值为1则表示没有人使用临界区,当值为0表示临界区正在使用中。
    假设线程T2正在使用临界区,那么它遵循以下步骤。
    T2:

  • wait(s)//最初s值在调用之后等于它的值减少了1,即0
  • 使用关键部分
  • signal(s)//现在s值增加,变为1
  • Mutex和Binary信号量之间的主要区别在于Mutext如果线程锁定临界区然后它必须解锁临界区而没有其他线程可以解锁它,但是在Binary信号量的情况下如果一个线程使用wait(s)函数锁定临界区然后值s变为"0"并且没有人可以访问它,直到"s"的值变为1但是假设某些其他线程调用信号然后"s"的值变为1并且它允许其他功能使用临界区。
    因此在Binary信号量线程中没有所有权。


    互斥锁用于"锁定机制"。一次一个进程可以使用共享资源

    信号量用于"信号机制"
    喜欢"我完成了,现在可以继续"


    在Windows上,互斥锁和二进制信号量之间存在两个不同之处:

  • 互斥锁只能由拥有所有权的线程释放,即先前调用Wait函数的线程(或者在创建它时获得所有权)。任何线程都可以释放信号量。

  • 线程可以在互斥锁上重复调用等待函数而不会阻塞。但是,如果在二进制信号量上调用等待函数两次而不释放其间的信号量,则线程将阻塞。


  • 你显然使用互斥锁来锁定一个线程中的数据,同时被另一个线程访问。假设您刚刚调用了lock()并且正在访问数据。这意味着您不希望任何其他线程(或相同线程代码的另一个实例)访问由同一个互斥锁锁定的相同数据。也就是说,如果在不同的线程实例上执行相同的线程代码,则命中锁,然后lock()应该阻止那里的控制流。这适用于使用不同线程代码的线程,该线程代码也访问相同的数据,并且也被同一个互斥锁锁定。在这种情况下,您仍然在访问数据,并且您可能需要另外15秒来达到互斥锁解锁(以便在互斥锁中被阻止的另一个线程将解锁并允许控制访问数据)。您是否不惜一切代价允许另一个线程解锁相同的互斥锁,反过来又允许已经在互斥锁中等待(阻塞)的线程解除阻塞并访问数据?希望你能得到我在这里说的话?
    根据,同意普遍定义!,

    • 用"互斥"这种情况不可能发生。没有其他线程可以解锁
      在你的线程中
    • 使用"二进制信号量"可能会发生这种情况。任何其他线程都可以解锁
      锁定你的线程

    所以,如果你非常特别使用二进制信号量而不是互斥量,那么你应该非常小心地"确定"锁定和解锁。我的意思是,每次锁定的每个控制流都应该打一个解锁电话,也不应该有任何"第一次解锁",而应该始终是"第一次锁定"。


    神话:

    几篇文章说"二进制信号量和互斥量相同"或"值为1的信号量是互斥量",但基本的区别是Mutex只能由获取它的线程释放,而你可以从任何其他线程发出信号量信号

    关键点:

    ?一个线程可以获得多个锁(Mutex)。

    ?只有当互斥锁是一个递归互斥锁时,互斥锁才能被锁定多次,这里互斥锁的解锁和解锁应该相同

    ?如果已经锁定了互斥锁的线程再次尝试锁定互斥锁,它将进入该互斥锁的等待列表,从而导致死锁。

    ?二进制信号量和互斥量相似但不相同。

    ?Mutex由于与之相关的保护协议而成本高昂。

    ?互斥的主要目的是实现原子访问或锁定资源


    Mutex控制对单个共享资源的访问。它提供了获取()访问该资源的操作,并在完成后释放()它。

    信号量控制对共享资源池的访问。它向Wait()提供操作,直到池中的一个资源变为可用,并将Signal()提供给池。

    当信号量保护的资源数大于1时,它被称为计数信号量。当它控制一个资源时,它被称为布尔信号量。布尔信号量相当于互斥锁。

    因此,信号量是一种比Mutex更高级别的抽象。可以使用信号量实现互斥锁,但不能相反。


    修改过的问题是 -"Linux"中的互斥锁和"二进制"信号量有什么区别?

    答:以下是差异 -
    i)范围 - 互斥体的范围在创建它的进程地址空间内,并用于线程的同步。信号量可以跨进程空间使用,因此可以用于进程间同步。

    ii)Mutex比信号量轻,速度快。 Futex甚至更快。

    iii)互斥锁可以被同一个线程多次成功获取,条件是它应该释放相同的次数。尝试获取的其他线程将阻止。而在信号量的情况下,如果相同的进程再次尝试获取它,则它会阻塞,因为它只能被获取一次。


    Mutex致力于阻止关键区域,但Semaphore依赖于计数。


    Binary Semaphore和Mutex之间的区别:
    所有权:
    信号量甚至可以从非当前所有者发出信号(发布)。这意味着您可以简单地从任何其他线程发布,但您不是所有者。

    信号量是一个正在处理的公共财产,它可以简单地由非所有者线程发布。
    请用粗体字母标记这个区别,这意味着很多。


    http://www.geeksforgeeks.org/archives/9102详细讨论。

    Mutex是用于同步对资源的访问的锁定机制。
    Semaphore是信令机制。

    如果他/她想使用二进制信号量代替互斥锁,那么它应该由程序员完成。


    除了互斥锁具有所有者之外,这两个对象可以针对不同的用途进行优化。互斥锁的设计只能在短时间内保存;违反此规定可能会导致性能不佳和不公平的安排。例如,可以允许正在运行的线程获取互斥锁,即使另一个线程已经被阻塞。信号量可以提供更多的公平性,或者可以使用多个条件变量来强制公平。


    经过上述帖子后,这个概念对我来说很清楚。但是有一些挥之不去的问题。所以,我写了这段小代码。

    当我们试图给出一个信号量而不接受它时,它就会通过。但是,当你尝试不使用互斥锁时,它会失败。我在Windows平台上测试了这个。启用USE_MUTEX以使用MUTEX运行相同的代码。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    #include <stdio.h>
    #include <windows.h>
    #define xUSE_MUTEX 1
    #define MAX_SEM_COUNT 1

    DWORD WINAPI Thread_no_1( LPVOID lpParam );
    DWORD WINAPI Thread_no_2( LPVOID lpParam );

    HANDLE Handle_Of_Thread_1 = 0;
    HANDLE Handle_Of_Thread_2 = 0;
    int Data_Of_Thread_1 = 1;
    int Data_Of_Thread_2 = 2;
    HANDLE ghMutex = NULL;
    HANDLE ghSemaphore = NULL;


    int main(void)
    {

    #ifdef USE_MUTEX
        ghMutex = CreateMutex( NULL, FALSE, NULL);
        if (ghMutex  == NULL)
        {
            printf("CreateMutex error: %d
    ", GetLastError());
            return 1;
        }
    #else
        // Create a semaphore with initial and max counts of MAX_SEM_COUNT
        ghSemaphore = CreateSemaphore(NULL,MAX_SEM_COUNT,MAX_SEM_COUNT,NULL);
        if (ghSemaphore == NULL)
        {
            printf("CreateSemaphore error: %d
    ", GetLastError());
            return 1;
        }
    #endif
        // Create thread 1.
        Handle_Of_Thread_1 = CreateThread( NULL, 0,Thread_no_1, &Data_Of_Thread_1, 0, NULL);  
        if ( Handle_Of_Thread_1 == NULL)
        {
            printf("Create first thread problem
    ");
            return 1;
        }

        /* sleep for 5 seconds **/
        Sleep(5 * 1000);

        /*Create thread 2 */
        Handle_Of_Thread_2 = CreateThread( NULL, 0,Thread_no_2, &Data_Of_Thread_2, 0, NULL);  
        if ( Handle_Of_Thread_2 == NULL)
        {
            printf("Create second thread problem
    ");
            return 1;
        }

        // Sleep for 20 seconds
        Sleep(20 * 1000);

        printf("Out of the program
    ");
        return 0;
    }


    int my_critical_section_code(HANDLE thread_handle)
    {

    #ifdef USE_MUTEX
        if(thread_handle == Handle_Of_Thread_1)
        {
            /* get the lock */
            WaitForSingleObject(ghMutex, INFINITE);
            printf("Thread 1 holding the mutex
    ");
        }
    #else
        /* get the semaphore */
        if(thread_handle == Handle_Of_Thread_1)
        {
            WaitForSingleObject(ghSemaphore, INFINITE);
            printf("Thread 1 holding semaphore
    ");
        }
    #endif

        if(thread_handle == Handle_Of_Thread_1)
        {
            /* sleep for 10 seconds */
            Sleep(10 * 1000);
    #ifdef USE_MUTEX
            printf("Thread 1 about to release mutex
    ");
    #else
            printf("Thread 1 about to release semaphore
    ");
    #endif
        }
        else
        {
            /* sleep for 3 secconds */
            Sleep(3 * 1000);
        }

    #ifdef USE_MUTEX
        /* release the lock*/
        if(!ReleaseMutex(ghMutex))
        {
            printf("Release Mutex error in thread %d: error # %d
    ", (thread_handle == Handle_Of_Thread_1 ? 1:2),GetLastError());
        }
    #else
        if (!ReleaseSemaphore(ghSemaphore,1,NULL) )      
        {
            printf("ReleaseSemaphore error in thread %d: error # %d
    ",(thread_handle == Handle_Of_Thread_1 ? 1:2), GetLastError());
        }
    #endif

        return 0;
    }

    DWORD WINAPI Thread_no_1( LPVOID lpParam )
    {
        my_critical_section_code(Handle_Of_Thread_1);
        return 0;
    }


    DWORD WINAPI Thread_no_2( LPVOID lpParam )
    {
        my_critical_section_code(Handle_Of_Thread_2);
        return 0;
    }

    事实上,信号量让你发出信号"它是使用资源完成的",即使它从未拥有资源,这让我觉得在信号量的情况下拥有和信令之间存在非常松散的耦合。


    在Windows中,差异如下。
    MUTEX:成功执行wait的进程必须执行信号,反之亦然。 BINARY SEMAPHORES:不同的进程可以对信号量执行等待或信号操作。


    虽然二进制信号量可以用作互斥锁,但互斥锁是更具体的用例,因为只有锁定互斥锁的进程才能解锁它。此所有权约束可以提供以下保护:

    • 意外释放
    • 递归死锁
    • 任务死亡僵局

    这些约束并不总是存在,因为它们会降低速度。在开发代码期间,您可以临时启用这些检查。

    例如您可以在互斥锁中启用错误检查属性。如果您尝试锁定相同的两次,则检查互斥锁的错误将返回EDEADLK,如果您解锁不属于您的互斥锁,则返回EPERM

    1
    2
    3
    4
    5
    pthread_mutex_t mutex;
    pthread_mutexattr_t attr;
    pthread_mutexattr_init (&attr);
    pthread_mutexattr_settype (&attr, PTHREAD_MUTEX_ERRORCHECK_NP);
    pthread_mutex_init (&mutex, &attr);

    初始化后,我们可以将这些检查放在我们的代码中,如下所示:

    1
    2
    3
    if(pthread_mutex_unlock(&mutex)==EPERM)
     printf("Unlock failed:Mutex not owned by this thread
    ");

    Mutex用于保护敏感代码和数据,信号量用于同步。您也可以实际使用保护敏感代码,但是可能存在通过操作V由其他线程释放保护的风险。双信号量和互斥量之间的区别就是所有权。例如通过厕所,Mutex就像是可以进入厕所并锁上门,没有其他人可以进入,直到男人离开,双信号量就像一个人可以进入厕所和锁门,但其他人可以通过要求管理员打开门进入,这是荒谬的。


    互斥

    互斥锁通常用于序列化对一部分可重入代码的访问,这些代码不能由多个线程同时执行。互斥对象只允许一个线程进入受控部分,强制其他尝试访问该部分的线程等到第一个线程退出该部分。正确使用互斥锁是为了保护共享资源可能有危险意想不到的副作用。任何两个以不同优先级运行并通过互斥锁协调的RTOS任务都会为优先级倒置创造机会。 Mutex在用户空间中工作。

    信号

    信号量是一种信号机制。信号量将共享资源的并发用户数限制为最大数量。线程可以请求访问资源(递减信号量)并且可以发信号通知他们已经完成使用资源(递增信号量)。它允许多个线程访问共享资源。信号量的正确使用是用于从一个任务到另一个任务的信令。信号量也可用于从中断服务例程(ISR)向任务发送信号。信令信令是一种非阻塞的RTOS行为,因此ISR是安全的。因为这种技术消除了在任务级别禁用中断的容易出错的需要。这在内核空间中有效。


    与信号量不同,互斥量具有所有权。虽然在互斥体范围内的任何线程都可以获得解锁的互斥锁并锁定对相同关键代码段的访问权限,但只有锁定互斥锁的线程才能解锁它。


    正如许多人提到的那样,互斥锁用于保护关键代码段(AKA关键部分)。您将在同一个线程中获取互斥锁(锁定),输入临界区,并释放互斥锁(解锁)。

    在使用信号量时,可以让线程等待信号量(比如线程A),直到另一个线程(比如线程B)完成任何任务,然后设置线程A的信号量以停止等待,并继续其任务。


    答案可能取决于目标操作系统。例如,我熟悉的至少一个RTOS实现将允许针对单个OS互斥锁进行多个顺序"获取"操作,只要它们都来自同一个线程上下文。在允许另一个线程获取互斥锁之前,必须用相同数量的put替换多个gets。这与二进制信号量不同,二进制信号量一次只允许一次获取,而不管线程上下文。

    这种互斥体背后的想法是通过仅允许单个上下文一次修改数据来保护对象。即使线程获得互斥锁,然后调用一个进一步修改对象的函数(并将保护器互斥锁置于其自己的操作周围),操作仍然应该是安全的,因为它们都发生在单个线程下。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    {
        mutexGet();  // Other threads can no longer get the mutex.

        // Make changes to the protected object.
        // ...

        objectModify();  // Also gets/puts the mutex.  Only allowed from this thread context.

        // Make more changes to the protected object.
        // ...

        mutexPut();  // Finally allows other threads to get the mutex.
    }

    当然,使用此功能时,您必须确保单个线程内的所有访问都是安全的!

    我不确定这种方法有多常见,或者它是否适用于我熟悉的系统之外。有关此类互斥锁的示例,请参阅ThreadX RTOS。


    互斥和二进制信号量都是相同的用法,但实际上它们是不同的。

    在互斥锁的情况下,只有锁定它的线程才能解锁它。如果任何其他线程锁定它,它将等待。

    在semaphone的情况下,情况并非如此。信号量与特定的线程ID无关。


    最佳方案

    唯一的区别是

    1.Mutex - >锁定和解锁是锁定互斥锁的线程的所有权

    2.信号量 - >没有所有权,即;如果一个线程调用semwait(s)任何其他线程可以调用sempost(s)来删除锁。


    "二进制信号量"是一种绕过使用信号量的编程语言?喜欢?互斥?显然有两个非常大的差异:

  • 你打电话给他们的方式。

  • "标识符"的最大长度。


  • 基本问题是并发性。控制流程不止一个。考虑使用共享内存的两个进程。现在,一次只能有一个进程访问共享内存。如果一次有多个进程访问共享内存,则共享内存的内容将被破坏。它就像一条铁轨。只有一列火车可以在它上面运行,否则就会发生意外。所以有一个信号机制,司机检查。如果信号为绿色,则列车可以行驶,如果是红色,则必须等待使用轨道。类似地,在共享内存的情况下,存在二进制信号量。如果信号量为1,则进程获取它(使其为0)并继续并访问它。如果信号量为0,则进程等待。二进制信号量必须提供的功能是互斥(或简称互斥),以便许多并发实体(进程或线程)中只有一个相互排除其他实体。我们计算信号量是一个优点,它有助于同步资源的多个实例。

    相互排斥是信号量提供的基本功能。现在在线程的上下文中,我们可能有不同的名称和语法。但基本概念是相同的:如何在并发编程中保持代码和数据的完整性。在我看来,所有权和相关检查之类的东西都是由实现提供的改进。


    几乎所有上述都说得对。如果有人仍有疑问,我还要试着澄清一下。
    互斥锁 - >用于序列化
    信号量 - >同步。
    然而,两者的目的不同,通过仔细编程可以通过它们实现相同的功能。
    标准示例 - >生产者消费者问题。
    SemaVar的初始值= 0

    制片人消费者
    --- SemaWait() - >减少SemaVar

    产生数据

    SemaSignal SemaVar或SemaVar ++ --->消费者解锁,因为SemVar现在是1。

    希望我能澄清一下。