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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

GHC - devs mailing list
#15267: Extend TVar/MVar to N capacity / Add primitive channal type
-------------------------------------+-------------------------------------
           Reporter:  winter         |             Owner:  (none)
               Type:  feature        |            Status:  new
  request                            |
           Priority:  high           |         Milestone:  8.6.1
          Component:  Runtime        |           Version:  8.4.3
  System                             |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 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.

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

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

GHC - devs mailing list
#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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
Reply | Threaded
Open this post in threaded view
|

Re: [GHC] #15267: Extend TVar/MVar to N capacity / Add primitive channel type (was: Extend TVar/MVar to N capacity / Add primitive channal type)

GHC - devs mailing list
In reply to this post by GHC - devs mailing list
#15267: Extend TVar/MVar to N capacity / Add primitive channel 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:                    |
-------------------------------------+-------------------------------------

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

_______________________________________________
ghc-tickets mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets