Build History for branch/add-lazy-queue

Add a "lazy" queue This essentially uses a "lazy" semi-immutable queue implemented using a mutable spine that is updated incrementally such that every operation on the queue is O(1). The lazy queue is then wrapped as a single atomic. This results in a relatively space efficient concurrent queue. Performance also seems relatively good with the obvious caveat that as only a single atomic is used, that atomic is a contention point, which somewhat limits scalability compared to queues that have separate mutable head and tail atomics.

Add a "lazy" queue This essentially uses a "lazy" semi-immutable queue implemented using a mutable spine that is updated incrementally such that every operation on the queue is O(1). The lazy queue is then wrapped as a single atomic. This results in a relatively space efficient concurrent queue. Performance also seems relatively good with the obvious caveat that as only a single atomic is used, that atomic is a contention point, which somewhat limits scalability compared to queues that have separate mutable head and tail atomics.

Hmm...

Test

Add a "lazy" queue This queue essentially uses a "lazy" semi-immutable queue implemented using a mutable spine that is updated incrementally such that every operation on the queue is O(1). The lazy queue is then wrapped as a single atomic. This results in a relatively space efficient concurrent queue. Performance also seems relatively good with the obvious caveat that as only a single atomic is used, that atomic is a contention point, which somewhat limits scalability compared to queues that have separate mutable head and tail atomics.

Test

Test

Add a "lazy" queue This queue essentially uses a "lazy" semi-immutable queue implemented using a mutable spine that is updated incrementally such that every operation on the queue is O(1). The lazy queue is then wrapped as a single atomic. This results in a relatively space efficient concurrent queue. Performance also seems relatively good with the obvious caveat that as only a single atomic is used, that atomic is a contention point, which somewhat limits scalability compared to queues that have separate mutable head and tail atomics.

Add a "lazy" queue This queue essentially uses a "lazy" semi-immutable queue implemented using a mutable spine that is updated incrementally such that every operation on the queue is O(1). The lazy queue is then wrapped as a single atomic. This results in a relatively space efficient concurrent queue. Performance also seems relatively good with the obvious caveat that as only a single atomic is used, that atomic is a contention point, which somewhat limits scalability compared to queues that have separate mutable head and tail atomics.

Add a "lazy" queue This queue essentially uses a "lazy" semi-immutable queue implemented using a mutable spine that is updated incrementally such that every operation on the queue is O(1). The lazy queue is then wrapped as a single atomic. This results in a relatively space efficient concurrent queue. Performance also seems relatively good with the obvious caveat that as only a single atomic is used, that atomic is a contention point, which somewhat limits scalability compared to queues that have separate mutable head and tail atomics.

Add a "lazy" queue This queue essentially uses a "lazy" semi-immutable queue implemented using a mutable spine that is updated incrementally such that every operation on the queue is O(1). The lazy queue is then wrapped as a single atomic. This results in a relatively memory efficient concurrent queue. Performance also seems relatively good with the obvious caveat that as only a single atomic is used, that atomic is a contention point, which somewhat limits scalability compared to queues that have separate mutable head and tail atomics.

Add a "lazy" queue This queue essentially uses a "lazy" semi-immutable queue implemented using a mutable spine that is updated incrementally such that every operation on the queue is O(1). The lazy queue is then wrapped as a single atomic. This results in a relatively memory efficient concurrent queue. Performance also seems relatively good with the obvious caveat that as only a single atomic is used, that atomic is a contention point, which somewhat limits scalability compared to queues that have separate mutable head and tail atomics.