What do you call a 1 element buffer?

[Aristos Queue]

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?

[chris754]

Capillary? or cell? (if you like biology references...)

Edited January 8, 2015 by chris754

[ned]

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"?

[drjdpowell]

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.

[JLMommy]

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

[ohiofudu]

I will recomend "FiFo Buffer"

[bbean]

Turnstile

[Darin]

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.

[eberaud]

It also makes me think of a DVR (Data Value Reference). So an acronym like SEP seems appropriate.

[ak_nz]

I like cell. Perhaps Slot?

[LogMAN]

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

[eberaud]

+1 for Register

[ShaunR]

 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)  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   (although if you concentrate on how transfers happen rather than what is transferred, I think it is more obvious)

Edited January 14, 2015 by ShaunR

[Aristos Queue]

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. :-) 

[ShaunR]

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 January 14, 2015 by ShaunR