Questions tagged «synchronization»

我试图理解Peterson和Dekker的算法，它们非常相似并且显示出很多对称性。 我试图用非正式语言来制定算法，如下所示： Peterson's: "I want to enter." flag[0]=true; "You can enter next." turn=1; "If you want to enter and while(flag[1]==true&&turn==1){ it's your turn I'll wait." } Else: Enter CS! // CS "I don't want to enter any more." flag[0]=false; Dekker's: "I want to enter." flag[0]=true; "If you want to enter …

41 concurrency  synchronization  mutual-exclusion 

锁通常通过测试设置和交换机器级指令来实现。是否有其他不使用这些实现的实现？ 另外，我们是否可以说，针对关键部分问题的所有硬件级解决方案都可以分为三类，即中断禁用，测试设置和交换？

19 concurrency  synchronization  mutual-exclusion 

我目前正在上大学的并行编程课程，最近我们开始谈论监视器的概念。虽然我了解相互排斥的必要性，但我不明白为什么要为此使用监视器。 据我了解，监视器可以确保在关键时刻始终只有一个或没有进程。我们可以使用信号量来实现这一目标。此外，我们使用信号量来实现监视器（或至少一种实现它们的可能性）。 那么，为什么我要实现与带有信号量的信号量完全相同的东西呢？我可以获得什么好处？

11 concurrency  synchronization  mutual-exclusion 

我的理解是，互斥锁的大多数流行实现（例如C ++中的std :: mutex）都不保证公平性 -也就是说，它们不保证在争用的情况下线程将按其获取锁的顺序进行操作。称为lock（）。实际上，甚至有可能（尽管希望很罕见）在争用较高的情况下，某些等待获取互斥锁的线程可能永远无法获取它。 对我而言，这似乎是无益的行为-在我看来，公平的互斥体所产生的行为更符合程序员的期望/期望。 给出互斥量通常不被实现为公平的原因是“性能”，但我想更好地理解这意味着什么-特别是，放宽互斥量的公平性要求如何提高性能？看起来“公平”的互斥锁似乎是微不足道的实现-只需将lock（）将调用线程附加到互斥锁的链表的末尾，然后再将其置于睡眠状态，然后使unlock（）从下一个弹出线程相同列表的开头并将其唤醒。 我在这里缺少什么互斥体实现的见解，可以解释为什么认为为了提高性能而牺牲公平性是值得的吗？

11 concurrency  synchronization  threads