我想了解一个简单的场景,在这个场景中,有那么多线程在竞争同步共享资源。只有一个线程肯定会获得资源上的锁,所有其他线程都必须等待,现在根据资源可用性,每个等待线程将再次尝试获取锁,如果失败,则再次挂起等待下一次尝试。这种情况不会增加上下文切换开销,因为线程一次又一次地挂起并恢复以获取资源。我只想问一问,同步开销和上下文交换开销之间是否存在直接成正比的关系? 2)在任何算法中引入更多的共享变量,都会增加上下文交换开销,即共享资源的数量与上下文交换开销之间存在一个直接成正比的关系。
我说的对吗?
现在,我的第二个问题是“如果在上述场景中使用非阻塞算法进行同步,即如果使用原子变量作为共享资源,那么在原子共享资源的情况下,上下文切换开销的影响是什么”。共享资源的竞争线程是否不会挂起或恢复,即如何处理这种非阻塞同步现象?
发布于 2015-01-22 23:00:36
等待线程不会导致永久上下文切换,请参见以下问题:上下文切换线程等待
(编辑:可能会发生一些上下文切换: JVM试图在短时间内尝试自旋锁,但在操作系统级别上暂停线程一段时间之后,如果这发生在其量程过期之前,那么这就是额外的上下文切换)
所有相关的状态变量都应该在单个原子操作中更新(例如,在单个同步块中),因此由同步引起的上下文切换不应该与变量的数量成正比。
原子变量试图使用专用CPU指令来实现原子性,因此这里不应该有上下文切换。
发布于 2015-01-28 05:37:55
假设没有使用wait()或notify()方法。这些似乎不在你的问题中。如果不是这样的话,请纠正。
在这种情况下,会有上下文开关,因为所有这些线程都将处于可运行状态,并将被调度为运行,并且会有上下文开关。您可以使用等待通知方法来减少这种情况。
如果您有更多的锁定,那么就会有更多的开销--这是正确的。
如果使用原子变量,那么这将利用compareAndSet方法,在分配给它的处理器片中,它们将尝试旋转以提供原子增量(参见Linux:调度器)。如果它不能执行原子增量,那么就不会有上下文切换,否则,当这个线程再次被切换回来时,就必须重新访问它。
希望这能有所帮助。
https://stackoverflow.com/questions/28097149
复制相似问题