Questions tagged «concurrency»

并发是其中多个进程同时执行的系统的属性。

8
“并行”执行与“并行”执行之间的区别？
是什么方面的区别并发和并行执行？我从来没有完全能够理解这种区别。 该标签将并发定义为同时运行两个进程的方式，但是我认为并行性是完全相同的事情，即：可能在单独的处理器上运行的单独的线程或进程。 另外，如果我们考虑使用异步I / O之类的东西，那么我们是在处理并发性还是并行性？
10
如何解释为什么多线程很难
我是一个相当不错的程序员，我的老板也是一个相当不错的程序员。尽管他似乎低估了诸如多线程之类的某些任务以及它的难度（我发现，除了运行几个线程，等待所有线程完成然后返回结果之外，其他事情非常困难）。 当您开始担心僵局和比赛条件时，我觉得这很困难，但老板似乎并不喜欢这一点-我认为他从未遇到过。只是打个锁就差不多了。 那么，我如何介绍他，或者解释为什么他可能低估了并发，并行和多线程的复杂性？还是我错了？ 编辑：他做了些什么-遍历一个列表，为该列表中的每个项目创建一个线程，该线程根据该项目中的信息执行数据库更新命令。我不确定他如何控制一次执行多少个线程，我想如果运行太多（如果他使用信号量的话），他一定会将它们添加到队列中。
6
对象池是否已被弃用？
我对对象池的概念非常熟悉，并且我总是尝试尽可能多地使用它。 另外，我一直认为对象池是标准规范，因为我已经观察到Java本身以及其他框架尽可能多地使用池。 最近，尽管我读了一些对我来说是全新的东西（并且违反直觉？）。 该池实际上使程序性能变差，尤其是在并发应用程序中，并且建议实例化new对象，因为在较新的JVM中，对象的实例化确实非常快。 我在书中读过： Java Concurrency in Practice 现在，我开始考虑我是否对这里的事情有所误解，因为本书的第一部分建议使用Executors重用Thread而不是创建新实例。 那么，如今对象池是否已被弃用？
1
纤维，协程和绿线之间有区别吗？
今天，我在互联网上阅读了几篇有关纤维，协程和绿色线程的文章，看来这些概念有很多共通之处，但还是存在细微的差异，尤其是当我们谈论纤维和协程时。 是否有一个简洁，正确的摘要来使它们彼此不同？ 更新：我发现区分协程和纤维（N4024 C ++草案）文档特别擅长区分纤维和协程。
1
go-langs goroutine池只是绿色线程吗？
在这里评论员提供绿色线程的批评如下： 最初，我是在N：M模型上出售的，这是一种使事件驱动的程序不带回调地狱的方法。您可以编写看起来像是古老的过程代码的代码，但是在其中有一种神奇之处是，只要有东西阻塞，它就会使用用户空间任务切换。听起来不错。问题在于，我们最终要用更多的复杂性来解决复杂性。swapcontext（）和family相当困难，其复杂性来自其他意外地方。 突然之间，您被迫编写了一个用户空间调度程序，并猜测编写一个调度程序确实很难做，而要使Linux的调度程序投入大量的精力，这将做得更好。现在，您希望您的日程表将N个绿色线程分配给M个物理线程，因此您不必担心同步。同步带来了性能问题，因此现在就开始您的工作吧，您将遇到一个新的无锁兔子洞。构建正确的高度并发调度程序绝非易事。 另一个批评是在这里： 伪造多个线程的单个进程存在很多问题。其中之一是，所有伪造的线程都会在任何页面错误时停止运行。 我的问题是- 是去浪的够程（用于默认池）只是绿色的线？如果是这样，他们是否解决了上述批评？
16
具有直观的并发编程抽象的现代编程语言
我对学习并发编程感兴趣，重点是应用程序/用户级别（而不是系统编程）。我正在寻找一种现代的高级编程语言，该语言提供用于编写​​并发应用程序的直观抽象。我想专注于提高生产率并隐藏并发编程复杂性的语言。 举个例子，我不认为用C，C ++或Java编写多线程代码是一个好选择，因为恕我直言，我的工作效率降低了，而且它们的编程模型也不直观。另一方面，提高生产率并提供更直观抽象的语言（例如Python和多处理模块，Erlang，Clojure，Scala等）将是不错的选择。 根据您的经验，您会推荐什么？为什么？ 编辑：谢谢大家的有趣的回答。很难尝试得出结论，因为有很多不错的候选人：Erlang，Clojure，Scala，Groovy以及Haskell。我以最有说服力的论据对答案进行了投票，但是在决定选择哪个候选人之前，我将尝试所有好的候选人：)
11
并发性：如何处理设计和调试实现？
我已经开发并发系统已有好几年了，尽管我缺乏正规的培训（即没有学位），但我对这个主题掌握得很好。最近至少有一些新的语言变得流行起来，这些语言至少是为了简化并发而设计的，例如Erlang和Go。似乎他们的并发方法呼应了我自己的经验，即如何使系统具有可伸缩性并利用多个内核/处理器/机器。 但是，我发现很少有工具可以帮助您可视化您打算做什么，并可以验证您至少与最初的设想接近。使用非专为并发设计的语言（例如C / C ++，C＃，Java等），调试并发代码可能是一场噩梦。特别是，几乎不可能在开发环境中的一个系统上重新创建容易发生的条件。 那么，您设计系统来处理并发和并行处理的方法是什么？例子： 您如何确定可以同时进行的和必须进行顺序的？ 您如何重现错误条件并查看应用程序执行时发生的情况？ 您如何可视化应用程序的不同并发部分之间的交互？ 对于这些问题，我有自己的答案，但我还想了解更多。 编辑 到目前为止，我们有很多不错的建议。链接到的许多文章都非常好，我已经阅读了其中的一些文章。 我在并发编程方面的个人经历使我相信与顺序编程相比，您需要不同的思维方式。精神鸿沟可能与面向对象编程和过程编程之间的差异一样大。我希望这组问题更多地集中在系统地解决问题所必需的思维过程（即理论）上。提供更具体的答案时，有助于举例说明-您亲自进行了一些研究。 赏金目标 不要告诉我该怎么办。我已经控制住了。告诉我你做什么。告诉我您如何解决这些问题。
7
我是否应该不再使用不赞成使用的多线程和多处理器编程实践？
在FORTRAN和BASIC的早期，基本上所有程序都是使用GOTO语句编写的。结果是意大利面条代码，解决方案是结构化编程。 同样，指针可能很难控制我们程序中的特征。C ++从大量的指针开始，但是建议使用引用。像STL这样的库可以减少我们的依赖。还有一些习惯用法来创建具有更好特性的智能指针，并且某些版本的C ++允许引用和托管代码。 诸如继承和多态性之类的编程实践在幕后使用了许多指针（就像结构化编程生成充满分支指令的代码一样）。像Java这样的语言消除了指针，并使用垃圾回收来管理动态分配的数据，而不是依赖程序员来匹配其所有new和delete语句。 在我的阅读中，我看到了似乎不使用信号量的多进程和多线程编程的示例。他们是使用同一名称使用不同的名称还是使用新的方法来保护资源并发使用？ 例如，使用多核处理器进行多线程编程的系统的特定示例是OpenMP。它代表以下一个关键区域，不使用信号量，该信号量似乎不包含在环境中。 th_id = omp_get_thread_num(); #pragma omp critical { cout << "Hello World from thread " << th_id << '\n'; } 本示例摘自：http : //en.wikipedia.org/wiki/OpenMP 或者，使用带有功能wait（）和signal（）的信号量对线程进行类似的保护，如下所示： wait(sem); th_id = get_thread_num(); cout << "Hello World from thread " << th_id << '\n'; signal(sem); 在此示例中，事情非常简单，只需简单的回顾就足以显示wait（）和signal（）调用是匹配的，即使有很多并发，也可以提供线程安全性。但是其他算法更复杂，并且使用多个信号量（二进制和计数），这些信号量分布在具有复杂条件的多个函数中，可以被许多线程调用。创建死锁或无法使线程安全的后果很难管理。 这些系统（例如OpenMP）是否消除了信号量的问题？ 他们是否将问题转移到其他地方？ 如何使用算法将自己喜欢的信号量转换为不再使用信号量？
2
Rust如何与C ++的并发功能相区别？
问题 我试图了解Rust是否从根本上充分改善了C ++的并发功能，以便决定我是否应该花时间学习Rust。 具体来说，惯用的Rust如何改善惯用的C ++的并发功能，或以任何方式背离？ 改进（或分歧）主要是句法上的，还是范式上的实质改进（分歧）？或者是别的什么？还是根本就没有改善（分歧）？ 基本原理 最近，我一直在尝试自学C ++ 14的并发功能，感觉有些不对劲。感觉有些不对劲。什么感觉了吗？很难说。 当涉及到并发时，似乎编译器似乎并没有真正在帮助我编写正确的程序。感觉好像我在使用汇编程序而不是编译器。 诚然，当涉及到并发时，我完全有可能遭受一个微妙的，错误的概念。也许我还没有摆脱Bartosz Milewski在有状态编程和数据竞赛之间的紧张关系。也许我不太了解编译器中有多少合理的并发方法以及操作系统中有多少并发方法。
35 c++  concurrency  rust  c++14 
5
电影院座位预订系统如何防止多个用户预订相同的座位？
在电影院里，我去那里有售票亭，您可以选择想要的座位。他们也有一个相同的网站（该网站还有一个倒计时计时器，例如30秒，您必须在其中选择座位）。 虽然我了解诸如数据库事务之类的知识以及处理多个同时用户的其他技术，但我还是无法理解如何允许多个人同时选择一个席位；是否像第一个按“购买”的人那样简单，然后另一个人将收到错误消息，还是我错过了什么？
3
为什么不绿线？
虽然我知道有关此问题的问题已经解决（例如https://stackoverflow.com/questions/5713142/green-threads-vs-non-green-threads），但我感觉自己并没有一个令人满意的答案。 问题是：为什么JVM不再支持绿色线程？ 它在代码样式的Java FAQ上说了这一点： 绿色线程是指Java虚拟机（JVM）的一种操作模式，其中所有代码都在单个操作系统线程中执行。 然后在java.sun.com上： 不利之处在于，使用绿色线程意味着Linux上的系统线程无法得到利用，因此当添加其他CPU时Java虚拟机无法扩展。 在我看来，JVM可以具有等于内核数量的系统进程池，然后在此之上运行绿色线程。当您有大量经常阻塞的线程时（这可能是由于当前JVM限制了线程数），这可能会带来一些很大的优势。 有什么想法吗？
4
我应该坚持还是放弃Python来处理并发性？
我有一个10K LOC写在项目的Django用相当便宜的芹菜（RabbitMQ的用于在需要异步和后台作业），并已得出结论，该系统的部分将来自于被改写受益的东西比Django的其它更好的并发。原因包括： 信号处理和可变对象。特别是当一个信号触发另一个信号时，当实例更改或消失时，使用ORM在Django中处理它们可能会令人惊讶。我想使用某种消息传递方法，其中传递的数据在处理程序中不会更改（如果我正确的话，Clojure的写时复制方法看起来不错）。 系统的某些部分不是基于Web的，因此需要更好的支持来同时执行任务。例如，系统读取NFC标签，当读取一个NFC标签时，LED点亮几秒钟（Celery任务），播放声音（其他Celery任务），并查询数据库（其他任务）。这是作为Django管理命令实现的，但是Django及其ORM本质上是同步的并且共享内存是有限的（我们正在考虑增加更多的NFC读取器，我认为Django + Celery方法不再可行，我希望看到更好的消息传递功能）。 与使用诸如Erlang或Clojure这样的语言相比，使用Twisted或Tornado之类的利弊是什么？我对实际的利益和损害感兴趣。 您如何得出结论，系统的某些部分使用另一种语言会更好？您是否遇到性能问题？这些问题有多严重？如果可以更快，那么是否必须更快？ 示例1： Django在HTTP请求之外工作： 读取NFC标签。 已查询数据库（可能还有LDAP），并且我们希望在数据可用时执行某些操作（红灯或绿灯，播放声音）。这会使用Django ORM进行阻止，但是只要有Celery工作人员可用，就没有关系。更多工作站可能是个问题。 示例2：使用Django信号进行“消息传递”： 一个post_delete事件被处理，其他的对象可能是因为这个被修改或删除。 最后，应将通知发送给用户。在这里，如果传递给通知处理程序的参数是已删除或将要删除的对象的副本并保证在处理程序中不发生更改，那将是很好的。（当然，可以简单地通过不将ORM管理的对象传递给处理程序来手动完成。）
3
我应该在锁语句中放置多少工作？
我是一名初级开发人员，致力于为从第三方解决方案接收数据，将其存储在数据库中，然后将数据整理以供其他第三方解决方案使用的软件编写更新。我们的软件作为Windows服务运行。 查看以前版本中的代码，我看到以下内容： static Object _workerLocker = new object(); static int _runningWorkers = 0; int MaxSimultaneousThreads = 5; foreach(int SomeObject in ListOfObjects) { lock (_workerLocker) { while (_runningWorkers >= MaxSimultaneousThreads) { Monitor.Wait(_workerLocker); } } // check to see if the service has been stopped. If yes, then exit if (this.IsRunning() == …
27 c#  .net  concurrency  locks 
3
多线程应用程序的UML图
对于单线程应用程序，我喜欢使用类图来概述该应用程序的体系结构。但是，在尝试了解大量的多线程/并发应用程序时，这种类型的图并不是很有用，例如，因为类的不同实例在不同的线程上“处于活动状态”（意味着访问一个实例仅从一个实例中保存）线程继续存在）。因此，类之间的关联并不一定意味着我可以在那些对象上调用方法，而是必须在目标对象的线程上进行该调用。 我在该主题上挖掘过的大多数文献 ，例如Hassan Gomaa的UML设计并发，分布式和实时应用程序，都有一些不错的主意，例如将线程边界绘制到对象图中，但总体而言似乎有点学术性和冗长性真的很有用。 我不想将这些图用作问题域的高级视图，而只是作为我的类/对象，它们之间的相互作用以及我上面提到的线程边界所造成的限制的详细描述。 因此，我想知道： 您发现哪种类型的图对理解多线程应用程序最有帮助？ 对经典UML的扩展是否考虑了多线程应用程序的特殊性，例如通过说明 有些对象可能生活在某个线程中，而另一些对象则没有线程亲和性； 对象的某些字段可以从任何线程读取，但只能从一个线程写入。 有些方法是同步的并返回结果，而另一些方法则是异步的，这些方法使请求排队，并例如通过不同线程上的回调返回结果。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.