Questions tagged «concurrency»

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

11 concurrency  synchronization  mutual-exclusion 

饮料分配器要求用户插入硬币（），然后按三个按钮之一：要求喝杯茶，同上咖啡，要求退款（即机器退回硬币：）。可以通过以下CCS流程对分配器进行建模：c¯c¯\bar cd¯tead¯tea\bar d_{\text{tea}}eteaeteae_{\text{tea}}r¯r¯\bar rb¯b¯\bar b M=defc.(dtea.e¯tea.M+dcoffee.e¯coffee.M+r.b¯.M)M=defc.(dtea.e¯tea.M+dcoffee.e¯coffee.M+r.b¯.M) M \stackrel{\mathrm{def}}= c.(d_{\text{tea}}.\bar e_{\text{tea}}.M + d_{\text{coffee}}.\bar e_{\text{coffee}}.M + r.\bar b.M) 内战将咖啡的价格提高到两枚硬币，而茶的价格仍然是一枚硬币。我们想要一台经过改进的机器，该机器仅在两枚硬币后才送出咖啡，并默认一枚或两枚硬币后才能退款。我们如何使用CCS流程对修改后的机器建模？

11 logic  concurrency  modelling  process-algebras  ccs 

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

11 concurrency  synchronization  threads 

我的背景来自命令式语言，主要是C，C ++和Python。几年后，我学习了Scala，Erlang和一些Haskell，从那以后，我对函数式编程及其背后的形式形式变得非常感兴趣。 我对并发和分布式编程也很感兴趣，并且一直在研究其背后的形式主义，特别是那些至少看到了一点点“日光”的形式主义（例如，在现实世界中的使用，或者至少是某个地方的实现）。到目前为止，我知道通信顺序过程，Actor模型，通信过程的代数以及通信系统的微积分。在我当中，我知道Actor模型已经以Erlang，Scala和Haskell等语言实现了。 我想知道在解决这些领域之前是否应该学习和实践一些基础，是否应该首先学习“经典”基础，以及是否可能错过其他流行的基础？

10 distributed-systems  concurrency 

给定一个由变量和修改这些变量的指令组成的程序以及一个同步原语（监视器，互斥锁，java的同步或C＃的锁），是否有可能证明该程序是线程安全的？ 甚至没有正式的模型来描述诸如线程安全性或比赛条件之类的东西吗？

9 proof-techniques  correctness-proof  concurrency  threads 

我认为在Peterson的互斥算法中，如果首先进入关键部分的过程死亡或被取消，则另一个过程将永远循环，等待进入关键部分。 在图中，如果进程1停止，则进程1后面的其余进程将执行到进程1所在的位置，然后循环执行。 如果到达关键部分的过程在离开之前先死了，会发生什么？

9 programming-languages  concurrency  mutual-exclusion