На Linux park реализован (в случае когда нужно действительно усыпить поток) через pthread_mutex_trylock+pthread_cond_wait (то есть на самом деле там внутри блокировочка) а на Windows через event объект и WaitForSingleObject на нем (то есть реально без блокировки).
Это не thread sleep, но ОС забирает контекст у потока до наступления события, чтобы впустую не жечь CPU.
Всё давно придумано, в том числе очереди. Есть вагон библиотек, в том числе стандартных. В Java, например, ConcurrentLinkedQueue реализует уже ставший классическим алгоритм очереди без блокировки Майкла-Скота https://www.research.ibm.com/people/m/michael/podc-1996.pdf Он очень хорошо масштабируется. На 100500 ядрах, конечно, не взлетит, но когда ядер очень уже много, то писать гарантированно FIFO очереди вообще вредно. Придумана масса почти-FIFO очередей и других трюков, котрые отлично масштабируются.
Comments 6
(The comment has been removed)
А бегать по кругу не только формально lock-free, но и на практике wait-free. То есть не просте не бяка, а очень даже наоборот супер. http://research.microsoft.com/pubs/209106/paper.pdf
На практике, однако, в CAS-retry цикле считать сколько раз прокрутитились и если долго крутимся, то какую-нибудь случайную задержку начинать втыкать.
Reply
(The comment has been removed)
Всё давно придумано, в том числе очереди. Есть вагон библиотек, в том числе стандартных. В Java, например, ConcurrentLinkedQueue реализует уже ставший классическим алгоритм очереди без блокировки Майкла-Скота https://www.research.ibm.com/people/m/michael/podc-1996.pdf Он очень хорошо масштабируется. На 100500 ядрах, конечно, не взлетит, но когда ядер очень уже много, то писать гарантированно FIFO очереди вообще вредно. Придумана масса почти-FIFO очередей и других трюков, котрые отлично масштабируются.
Reply
Спасибо за выступление, было интересно!
Reply
Reply
Leave a comment