[Haskell-cafe] Re: Concurrency questions
Ben Franksen <[EMAIL PROTECTED]> wrote: > Spencer Janssen wrote: > > On Sun, Jan 06, 2008 at 11:30:53AM +, Andrew Coppin wrote: > >> 1. Is there some way to assign a "priority" to Haskell threads? > >> (The behaviour I'd like is that high priority threads always run > >> first, and low priority threads potentially never run at all > >> unless there's an available processor which is completely idle.) > > > > Not in the current system. It is not clear that thread priorities > > are so nice anyway (see 'priority inversion' on Wikipedia, for > > example). > > As the wikipedia page also mentions well-known counter-measures, such > as priority inheritance and priority ceilings. For real-time > applications, priorities are a /must have/. Or at least, I can't see > anything nicer that could replace them. > Preemption, for hard real-time. For soft real-time, yes, SCHED_FIFO and SCHED_RR are a must. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Concurrency questions
Spencer Janssen wrote: > On Sun, Jan 06, 2008 at 11:30:53AM +, Andrew Coppin wrote: >> 1. Is there some way to assign a "priority" to Haskell threads? (The >> behaviour I'd like is that high priority threads always run first, and >> low priority threads potentially never run at all unless there's an >> available processor which is completely idle.) > > Not in the current system. It is not clear that thread priorities are so > nice anyway (see 'priority inversion' on Wikipedia, for example). As the wikipedia page also mentions well-known counter-measures, such as priority inheritance and priority ceilings. For real-time applications, priorities are a /must have/. Or at least, I can't see anything nicer that could replace them. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Concurrency questions
Andrew Coppin wrote: 2. You have to take the data out of an MVar to read it. In other words, only 1 thread can read an MVar at once [by design]. This isn't truly a problem in the current case, but it's irritating in principle that I can't make it so that once the cell is written, multiple threads can read it simultaneously... This is also known as I-structures i.e. IVar. I think you can simulate them via MVar with the readMVar function? Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Concurrency questions
Andrew Coppin wrote: > Felipe Lessa wrote: >> On Jan 6, 2008 9:30 AM, Andrew Coppin <[EMAIL PROTECTED]> >> wrote: >> >>> 2. I have a situation where I have a thread generating some data and >>> putting it into a mutable array, and another thread trying to read that >>> data. Is there a way I can make the reader thread block if it tries to >>> read a cell that hasn't been computed yet, but not introduce too much >>> overhead for cells that have been filled in? I am fairly sure that this is not possible with an MVar that contains the whole array. You could, however, keep the information about which elements have already been initialized in a separate data structure, for instance a set of indices (using e.g. Data.IntSet) >> If your thread fills the array linearly, you could maintain a variable >> shared by those threads that say the last cell computed, and have the >> read thread check that before reading. I think this wouldn't create >> too much overhead, although it seems like there must be something >> cleverer somewhere. >> > > That's just it - it fills the array in a fairly random order. (The > *scanning* is, however, in linear order.) > > It's not a big problem - I can wait for the entire array to be filled, > and then scan it. But I'd like to do both in parallel if there's a > reasonably easy way to do it. > > I suppose an array of MVars would do it, but > > 1. How big is an MVar? > > 2. You have to take the data out of an MVar to read it. In other words, > only 1 thread can read an MVar at once [by design]. This isn't truly a > problem in the current case, but it's irritating in principle that I > can't make it so that once the cell is written, multiple threads can > read it simultaneously... I first thought that Control.Concurrent.SampleVar would be your solution but nope, reading it still makes it empty. Have you tried STM and TVar? (I mean, an array of TVars). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Concurrency questions
Andrew Coppin <[EMAIL PROTECTED]> wrote: > 2. I have a situation where I have a thread generating some data and > putting it into a mutable array, and another thread trying to read > that data. Is there a way I can make the reader thread block if it > tries to read a cell that hasn't been computed yet, but not introduce > too much overhead for cells that have been filled in? > This http://www.haskell.org/ghc/docs/latest/html/libraries/stm/Control-Concurrent-STM-TChan.html could be what you're looking for. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
