Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,320
    • Issues 4,320
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 359
    • Merge Requests 359
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #15267

Closed
Open
Opened Jun 13, 2018 by winter@trac-winter

Extend TVar/MVar to N capacity / Add primitive channel type

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

Edited Mar 10, 2019 by winter
Assignee
Assign to
9.2.1
Milestone
9.2.1
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#15267