[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