Jump to content
Aristos Queue

What do you call a 1 element buffer?

Recommended Posts

Got an API that I'm helping to review. It has options for communication over a "Buffer" or a "Pipe". Reading the documentation, a pipe is an open-ended queue of values; a buffer is a single-element bounded queue.

 

I have trouble remembering which is one element and which is N elements. I suggested renaming "Buffer" as "1 Element Pipe," but the developer really wants a single term to describe each as it does (I agree) make a lot of the rest of the documentation easier to write. We also don't want to use the term "queue" because the actual implementation may or may not be a LabVIEW queue (depending upon how other things get configured, the system chooses the best actual implementation).

 

Does anyone have good terms to recommend for these two settings? In particular, I'd like a term that means "single element pipe". We've discussed "Tag," but this is a queue, not a variable -- the value gets removed by the reader. "Variable" gets rejected for similar reasons.

 

Thoughts?

Share this post


Link to post
Share on other sites

It's not quite right, but what's coming to mind is "Elevator" and "Escalator" - one transports a fixed number of items between levels at a time, the other transports items continuously. Maybe keep "Pipe," and replace "Buffer" with "Bucket" or "Bin"?

Share this post


Link to post
Share on other sites

Off topic: Came across the concept of a zero-element queue the other day.   Enqueue blocks until another process calls Dequeue, and then they both execute at the same time, passing the element across.

Share this post


Link to post
Share on other sites

The only thing I can think of that goes with the pipe analogy is "segment".  That to me means a piece of pipe.  

Share this post


Link to post
Share on other sites

I may or may not have an opinion about 'pipes' being appropriately used in this case, but that is beside the point.  If the object is a "pipe with one element" than it is a pipe and that is what it should be called.  In the documentation you can create an acronym or initialization or abbreviation, but that is what I think it should be instead of a new name.  You define it the first time you use it (or perhaps the first time in each section if you want) and then use the shorthand version.  For example, a single element queue is a queue, it does not need a new name.  If you get tired of writing it then simply write a single element queue (SEQ) and carry on.  A single element pipe (SEP) is one option.  I'd rather describe it as a blocking pipe or non-blocking pipe, or as the choice whether or not to enable spooling or buffering on the pipe.

Share this post


Link to post
Share on other sites

How about Register? You can read and write an register, but you could never add another element to it.

  • Like 1

Share this post


Link to post
Share on other sites

 a buffer is a single-element bounded queue.

 

I disagree with this statement. You can only access elements in order, for a queue and only at the end (FIFO, LIFO etc). That is not a restriction for a buffer which is just a common usage term for a storage area that tends to be (but isn't required to be) an intermediate step in processing. Unlike a queue it can be accessed any way you choose including randomly or in parallel, in chunks or whatever you decide. A buffer has more in common with streams than queues as streams are effectively managed buffers. 

 

As an exercise in pedantry (I think maybe in tune withe Darin here)  :D A Pipe is none of the above. It is a redirection. (Although for IPC it is usually realised with FIFOs).

 

However. I think you are trying to distinguish between a continuous flow with endpoints (like sockets) and  a global shared memory area that can be read and written to/from (like mmap).

 

So. I suggest the terms are correct. - [shared] Buffer and Pipe (although I would call the latter "stream" because I'm not a Linux fanatic). Maybe all that's required is a  mnemonic to remember which is which  :lol: (although if you concentrate on how transfers happen rather than what is transferred, I think it is more obvious)

Edited by ShaunR

Share this post


Link to post
Share on other sites

I disagree with this statement.

Disagree all you want -- my statement was assertive. In the current API, a "buffer" is a single element bounded queue. Sorry if I didn't make that clear.

 

Now, whether it should be or not, that is the open question. :-) 

Share this post


Link to post
Share on other sites

Disagree all you want -- my statement was assertive. In the current API, a "buffer" is a single element bounded queue. Sorry if I didn't make that clear.

 

Now, whether it should be or not, that is the open question. :-) 

Change the word *is* in the current APIs docs to *consists of*. Job done and you can move on :).

Edited by ShaunR

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.