英文:
How does a thread using AtomicInteger does less number of context switching?
问题
我正在研究AutomaticInteger。它指出使用AtomicInteger可以使整数操作变为非阻塞。据说AtomicInteger的compareAndSet()方法利用了比较并交换（Compare-and-set）特性。比较并交换特性在不成功时返回false。为了使比较并交换成功，AtomicInteger的compareAndSet()方法必须在无限循环中使用它。据说由于整数操作很小，与其切换上下文，等待在循环中更为有益。
据我理解，每个线程都有一定的固定时间片。如果一个线程在其时间片内无法完成工作，它将被抢占。然后它会在稍后再次有机会。
所以我的问题是：
- 在无法在Synchronized方法或块上获得锁之后，是否有任何线程在其时间片到期之前被抢占？如果是，那么该线程何时再次获得CPU时间？
- 在AtomicInteger类的compareAndSet()方法中存在一种自旋锁（无限循环），它是如何减少上下文切换时间的？
英文:
I was studying about AutomaticInteger. It stated that the use of an AtomicInteger makes an integer operation non-blocking. It is said that the compareAndSet() method of the AtomicInteger makes use of Compare-and-set feature. Compare-and-set feature returns false if it is not successful. To make Compare-and-set successful, compareAndSet() method of the AtomicInteger has to use it in an infinite loop. It is said that since the integer operations are small, it is more beneficial to wait in the loop than to switch the context.
To my understanding, every thread has a fixed time quanta available. If a thread cannot complete its work in its time quanta, it will have to be preempted. Then it will get a chance again later.
So my questions are:
- After being unable to gain a lock on the Synchronized method or block, is any thread preempted before its time quanta expire? If yes, when does that thread get CPU time again?
- How is a kind of spinlock (infinite loop) present in compareAndSet() method of AtomicInteger class able to reduce the context switch time?
答案1
得分: 3
> 在无法在同步方法或块上获得锁定后，是否会在线程的时间片用完之前被抢占？如果是，那么该线程什么时候再次获得 CPU 时间呢？
这取决于调度程序。但如果线程被抢占，那只是因为有其他线程可以立即取得前进。
> 在 AtomicInteger 类的 compareAndSet() 方法中，一种自旋锁（无限循环）是如何能减少上下文切换时间的？
仅当 AtomicInteger 被修改时，它才会循环，这意味着另一个线程取得了前进。两个线程无法同时修改同一个共享资源并在同一时间内取得前进。如果它经常循环，这意味着其他线程正在大量前进。在实际条件下，线程很少会自旋超过两次，而这仍然比不必要的上下文切换要更加节省成本。
英文:
> After being unable to gain a lock on the Synchronized method or block, is any thread preempted before its time quanta expire? If yes, when does that thread get CPU time again?
That's up to the scheduler. But if the thread gets pre-empted, it's only because there are other threads that can make immediate forward progress.
> How is a kind of spinlock (infinite loop) present in compareAndSet() method of AtomicInteger class able to reduce the context switch time?
It will only loop if the AtomicInteger was modified, in which case that means another thread made forward progress. Two threads can't make forward progress by modifying the very same shared resource at the very same time anyway. If it loops a lot, that means lots of forward progress is being made by other threads. In realistic conditions, it would be extraordinary rare for a thread to spin more than twice and that's still going to be cheaper than an unnecessary context switch.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论