0

I need to store a buffer of some values in STM. Writer threads need to monitor the buffer's size. I started to implement this thing using TChan but than I found out that the API does not provide a way to measure the length of the channel. Being a one stubborn fella I then implemented the thing myself:

readTChanLength ch = do
  empty <- isEmptyTChan ch
  if empty 
    then return 0
    else do
      value <- readTChan ch
      length <- readTChanLength ch
      unGetTChan ch value
      return $ 1 + length

Now everything works fine, but I am wondering what the reasons for such a trivial thing not to be implemented in the standard library are and what the preferred approach to that sorta problem is. I realize that this algorithm has at least an O(n) complexity, but it can't be the reason, right?

Nikita Volkov
  • 42,792
  • 11
  • 94
  • 169
  • What is the greater goal you are trying to accomplish? There might be a better pattern for what you want to do than reading the length. – yiding Jan 26 '13 at 23:53
  • @yiding The writer threads base their decision of whether to write new items to a channel based on how much items are already there. Just a standard buffer. – Nikita Volkov Jan 27 '13 at 00:14
  • My answer of using a counter should be good for this task. Or look at the bounded channels in the [stm-chans package](http://hackage.haskell.org/package/stm-chans-1.3.1). They track the counts with counters. – yiding Jan 27 '13 at 00:18

1 Answers1

3

The preferred approach is to keep a counter with the channel, and atomically increment the counter while writing the channel, and decrementing the counter when reading the channel.

Your solution traverses through all element of the channel, which will probably not work well for actual high-concurrent workloads.

yiding
  • 3,482
  • 18
  • 17
  • This approach hella reminds me of the standard imperative buggy pitfalls. Forget to increment the counter somewhere - and there you go, you have a nice bug untrackable by the typesystem. I agree that O(n) complexity may be too much for high loads, but that only makes me wonder why they didn't implement a wrapper type which keeps the track of the length. – Nikita Volkov Jan 27 '13 at 00:20
  • See stm-chans from comment above. – yiding Jan 27 '13 at 00:21
  • Thank you. "stm-chans" suggestion was useful, although it exhibits a different approach. – Nikita Volkov Jan 27 '13 at 00:48
  • 2
    "that only makes me wonder why they didn't implement a wrapper type which keeps the track of the length" @NikitaVolkov He's basically telling you that you can implement this wrapper yourself. Just create your own type, bundle the increment and decrement operations with the channel reads and writes and then don't expose the raw read and write operations. This guarantees that you will never forget to increment or decrement the counter. – Gabriella Gonzalez Jan 27 '13 at 17:05