Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #122594

Re: Concurrent API's and Semantics

From "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups comp.lang.c++
Subject Re: Concurrent API's and Semantics
Date 2025-08-19 14:19 -0700
Organization A noiseless patient Spider
Message-ID <1082pp8$3uotd$6@dont-email.me> (permalink)
References (2 earlier) <108081k$3crhp$1@dont-email.me> <1080auo$3dqgt$1@dont-email.me> <10823mt$3ppnu$1@dont-email.me> <1082niq$3uotd$1@dont-email.me> <1082pf1$3uotd$5@dont-email.me>

Show all headers | View raw

On 8/19/2025 2:14 PM, Chris M. Thomasson wrote:
> On 8/19/2025 1:42 PM, Chris M. Thomasson wrote:
>> On 8/19/2025 8:02 AM, jseigh wrote:
>>> On 8/18/25 18:54, Chris M. Thomasson wrote:
>>>> On 8/18/2025 3:04 PM, jseigh wrote:
>>>
>>>>>>
>>>>> Hints on the concurrent stack vs. concurrent queue.  It's not one 
>>>>> is LIFO
>>>>> and the other FIFO.
>>>>
>>>> Well, details matter here. Are we talking about spsc, mpsc, spmc, or 
>>>> mpmc? A concurrent stack can be using single word exchange and cas, 
>>>> a queue might use DWCAS and a dummy node, ect... Are we talking 
>>>> about node based or array based? We can have queues that are all 
>>>> implemented in different ways, it depends on how they are meant to 
>>>> be used...
>>>>
>>>
>>> Whatever would be equivalent to Java's ConcurrentQueue interface.
>>> Semantics for that and not specific to any implementation thereof.
>>
>> Bare bones for an API of such things:
>>
>> push
>> push_try
>> pop
>> pop_try
> 
> Heck! Actually, push/pop sure seem to imply waiting on an empty 
> predicate. So:
> 
> push_try
> pop_try
> 
> Is the boiled down main base API that covers most concurrent queues/stacks?
> 
> 
>>
>>
>> Heck adding in a get_count would add unneeded overhead. Heck why not 
>> add in the kitchen sink as well?
>>
>> Fwiw, imvho, push is generic and handles stacks and queues. Once we 
>> get verbose and say enqueue, well, that's too specific?
> 

Sorry Joe, for the flood. Just thinking here. The base API of push_try, 
and pop_try should be barebones baseline and even good enough to hook it 
up with an eventcount/futex to even implement push/pop with implied 
waiting? The *_try aspect of the API and the behavior should be 
compatible as predicates for an eventcount, a condvar for lock-free, in 
a sense? Futex is rather invasive, and an eventcount is rather generic 
wrt the *_try API?

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Concurrent API's and Semantics jseigh <jseigh_es00@xemaps.com> - 2025-08-18 13:24 -0400
  Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 13:06 -0700
    Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 13:23 -0700
    Re: Concurrent API's and Semantics jseigh <jseigh_es00@xemaps.com> - 2025-08-18 18:04 -0400
      Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 15:54 -0700
        Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-18 15:59 -0700
        Re: Concurrent API's and Semantics jseigh <jseigh_es00@xemaps.com> - 2025-08-19 11:02 -0400
          Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-19 13:34 -0700
            Re: Concurrent API's and Semantics jseigh <jseigh_es00@xemaps.com> - 2025-08-20 09:22 -0400
              Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-20 11:51 -0700
              Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-20 12:13 -0700
          Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-19 13:42 -0700
            Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-19 14:14 -0700
              Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-19 14:19 -0700
            Re: Concurrent API's and Semantics Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-20 18:25 +0200
              Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-20 11:53 -0700
                Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-20 12:00 -0700
                Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-20 12:05 -0700
                Re: Concurrent API's and Semantics Bonita Montero <Bonita.Montero@gmail.com> - 2025-09-10 17:39 +0200
                Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-09-10 13:14 -0700
                Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-09-10 14:20 -0700
  Re: Concurrent API's and Semantics Marcel Mueller <news.5.maazl@spamgourmet.org> - 2025-08-19 23:18 +0200
    Re: Concurrent API's and Semantics jseigh <jseigh_es00@xemaps.com> - 2025-08-20 09:35 -0400
      Re: Concurrent API's and Semantics Bonita Montero <Bonita.Montero@gmail.com> - 2025-08-20 18:35 +0200
        Re: Concurrent API's and Semantics "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-09-08 00:29 -0700

csiph-web