[GHC] #15267: Extend TVar/MVar to N capacity / Add primitive channal type

GHC ghc-devs at haskell.org
Wed Jun 13 03:24:34 UTC 2018


#15267: Extend TVar/MVar to N capacity / Add primitive channal type
-------------------------------------+-------------------------------------
        Reporter:  winter            |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  high              |            Milestone:  8.6.1
       Component:  Runtime System    |              Version:  8.4.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by winter:

Old description:

> The current concurrent primitives `TVar` and `MVar` have a fixed single
> capacity for holding the value to be synchronized. This pose great
> limitations on implementing many higher level concurrent structures
> efficiently, e.g. bound channel, semaphore, resource pool, etc. For
> example current <semaphore's implementation
> http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Control.Concurrent.QSem.html#signalQSem>
> is not ideal due to the extensive usage of multiple `MVar` s. If we have
> a good `BoundedChan a` type, semaphores can be easily implemented with
> `BoundedChan ()`.
>

> Currently we have various bound channel implementations, but these
> implementations are often not very efficient or too complex. For example
> the `BoundedChan` from <BoundedChan
> http://hackage.haskell.org/package/BoundedChan-1.0.3.0/docs/Control-
> Concurrent-BoundedChan.html> is based on an array of `MVar` s, thus
> consumes much more memory than a primitve channel which only have to
> record parked `StgTSO` s.
>
> I'm thinking adding something like:
>
> ```
> typedef struct {
>   StgHeader                  header;
>   struct StgMVarTSOQueue_   *head;
>   struct StgMVarTSOQueue_   *tail;
>   StgInt                     capacity;       // the channel's capacity
>   StgInt                     read_index;     // the reading end's index
>   StgInt                     write_index;    // the writing end's index
>   StgClosure                *payload[];      // payload array in
> continuous memory
> } StgMChan;
> ```
>
> I still can't work out all the details, but I'm confident something
> similar to this will work.

New description:

 The current concurrent primitives `TVar` and `MVar` have a fixed single
 capacity for holding the value to be synchronized. This pose great
 limitations on implementing many higher level concurrent structures
 efficiently, e.g. bound channel, semaphore, resource pool, etc. For
 example current
 [http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Control.Concurrent.QSem.html#signalQSem
 semaphore's implementation] is not ideal due to the extensive usage of
 multiple `MVar` s. If we have a good `BoundedChan a` type, semaphores can
 be easily implemented with `BoundedChan ()`.


 Currently we have various bound channel implementations, but these
 implementations are often not very efficient or too complex. For example
 the `BoundedChan` from
 [http://hackage.haskell.org/package/BoundedChan-1.0.3.0/docs/Control-
 Concurrent-BoundedChan.html BoundedChan] is based on an array of `MVar` s,
 thus consumes much more memory than a primitve channel which only have to
 record parked `StgTSO` s.

 I'm thinking adding something like:

 {{{
 typedef struct {
   StgHeader                  header;
   struct StgMVarTSOQueue_   *head;
   struct StgMVarTSOQueue_   *tail;
   StgInt                     capacity;       // the channel's capacity
   StgInt                     read_index;     // the reading end's index
   StgInt                     write_index;    // the writing end's index
   StgClosure                *payload[];      // payload array in
 continuous memory
 } StgMChan;
 }}}

 I still can't work out all the details, but I'm confident something
 similar to this will work.

--

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15267#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list