consume process hung

[singular-seal]

I'm using 2 disruptors and each has 6 consumers in my program. The consumers hung and 10 goroutines hung at DefaultWaitStrategy.Idle and 1 goroutine hung at DefaultWaitStrategy.Gate. 2 Producers hung at DefaultWriter.Reserve. The cpu usage is 200%(2 cores in 16 were full occupied).

I suspect it was cause by the busy waiting in DefaultWriter.Reserve,

if spin&SpinMask == 0 {
    runtime.Gosched() // LockSupport.parkNanos(1L); http://bit.ly/1xiDINZ
}

After replacing it with time.Sleep(100*time.Nanosecond), the issue was resolved.

[365318663]

I would like to know how to guarantee that writing and reading of ringBuffer is thread safe. Because I found that the writing and reading of the ringBuffer are not locked, and the data that may be read may not be written into the ringBuffer. Because of the MESI protocol, it does not guarantee good visibility.

[singular-seal]

There are atomic operations in writer.Commit which will make previous writings visible to other threads. The atomic operation in golang has similar semantics like volatile in java.

365318663 @.***> 于2023年5月5日周五 01:31写道：

I would like to know how to guarantee that writing and reading of ringBuffer is thread safe. Because I found that the writing and reading of the ringBuffer are not locked, and the data that may be read may not be written into the ringBuffer. [image: image] https://user-images.githubusercontent.com/45816584/236281289-eb1f299d-3ebe-42af-ada2-ada6563319f0.png

— Reply to this email directly, view it on GitHub https://github.com/smarty-prototypes/go-disruptor/issues/11#issuecomment-1535152432, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4MJVTVM7IKXIRRCE3EKIDXEPRYDANCNFSM6AAAAAARGEV3PQ . You are receiving this because you authored the thread.Message ID: @.***>

[365318663]

There are atomic operations in writer.Commit which will make previous writings visible to other threads. The atomic operation in golang has similar semantics like volatile in java. 365318663 @.> 于2023年5月5日周五 01:31写道： … I would like to know how to guarantee that writing and reading of ringBuffer is thread safe. Because I found that the writing and reading of the ringBuffer are not locked, and the data that may be read may not be written into the ringBuffer. [image: image] https://user-images.githubusercontent.com/45816584/236281289-eb1f299d-3ebe-42af-ada2-ada6563319f0.png — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4MJVTVM7IKXIRRCE3EKIDXEPRYDANCNFSM6AAAAAARGEV3PQ . You are receiving this because you authored the thread.Message ID: @.>

I think only the visibility of the index is guaranteed, but the visibility of the ringbuffer cannot be guaranteed?

[365318663]

There are atomic operations in writer.Commit which will make previous writings visible to other threads. The atomic operation in golang has similar semantics like volatile in java. 365318663 @.> 于2023年5月5日周五 01:31写道： … I would like to know how to guarantee that writing and reading of ringBuffer is thread safe. Because I found that the writing and reading of the ringBuffer are not locked, and the data that may be read may not be written into the ringBuffer. [image: image] https://user-images.githubusercontent.com/45816584/236281289-eb1f299d-3ebe-42af-ada2-ada6563319f0.png — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4MJVTVM7IKXIRRCE3EKIDXEPRYDANCNFSM6AAAAAARGEV3PQ . You are receiving this because you authored the thread.Message ID: @.>

I think only the visibility of the index is guaranteed, but the visibility of the ringbuffer cannot be guaranteed？

[singular-seal]

It can be deduced by the combination of sequenced before relation and synchronized before relation mentioned in https://go.dev/ref/mem . This doc https://segmentfault.com/a/1190000039729417 in Chinese explains more details about it.

365318663 @.***> 于2023年5月31日周三 21:33写道：

There are atomic operations in writer.Commit which will make previous writings visible to other threads. The atomic operation in golang has similar semantics like volatile in java. 365318663 @.

> 于2023年5月5日周五 01:31写道： … <#m5217545753462941596> I would like to know how to guarantee that writing and reading of ringBuffer is thread safe. Because I found that the writing and reading of the ringBuffer are not locked, and the data that may be read may not be written into the ringBuffer. [image: image] https://user-images.githubusercontent.com/45816584/236281289-eb1f299d-3ebe-42af-ada2-ada6563319f0.png https://user-images.githubusercontent.com/45816584/236281289-eb1f299d-3ebe-42af-ada2-ada6563319f0.png — Reply to this email directly, view it on GitHub <#11 (comment) https://github.com/smarty-prototypes/go-disruptor/issues/11#issuecomment-1535152432>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4MJVTVM7IKXIRRCE3EKIDXEPRYDANCNFSM6AAAAAARGEV3PQ https://github.com/notifications/unsubscribe-auth/AZ4MJVTVM7IKXIRRCE3EKIDXEPRYDANCNFSM6AAAAAARGEV3PQ . You are receiving this because you authored the thread.Message ID: @.>

I think only the visibility of the index is guaranteed, but the visibility of the ringbuffer cannot be guaranteed?

— Reply to this email directly, view it on GitHub https://github.com/smarty-prototypes/go-disruptor/issues/11#issuecomment-1570247718, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4MJVQT4KXKGAV3MPJUKP3XI5CD3ANCNFSM6AAAAAARGEV3PQ . You are receiving this because you authored the thread.Message ID: @.***>