读取文件时限制内存使用量

时间:2010-09-19 11:22:18

标签: haskell concurrency io heap-memory

我是Haskell的初学者,并认为这将是一个很好的练习。我有一个 赋值我需要在线程A中读取文件,处理文件行 在线程B_i中,然后在线程C中输出结果。

我已经实现了这一点,但其中一个要求就是我们 不能相信整个文件适合内存。我希望那个懒惰 IO和垃圾收集器会为我做这个,但唉内存使用情况 不断上升和上涨。

读者线程(A)使用readFile读取文件,然后压缩该文件 用行号和Just包裹。然后写入这些压缩的行 到Control.Concurrent.Chan。每个消费者线程B都有自己的渠道。

每个消费者在拥有数据和正则表达式时都会读取自己的频道 匹配,它输出到各自的输出通道包装 在Maybe(由列表组成)中。

打印机检查每个B线程的输出通道。如果没有 结果(行)为Nothing,打印行。从此以后 应该没有参考旧线,我以为是垃圾 收藏家将能够释放这些线,但唉,我似乎在 这里错了。

.lhs文件在这里: http://gitorious.org/hajautettujen-sovellusten-muodostamistekniikat/hajautettujen-sovellusten-muodostamistekniikat/blobs/master/mgrep.lhs

所以问题是,如何限制内存使用量或允许垃圾 收集器删除行。

根据要求提供的代码段。希望缩进不会被严重破坏:)

data Global = Global {done :: MVar Bool, consumers :: Consumers}
type Done = Bool
type Linenum = Int
type Line = (Linenum, Maybe String)
type Output = MVar [Line]
type Input = Chan Line
type Consumers = MVar (M.Map ThreadId (Done, (Input, Output)))
type State a = ReaderT Global IO a


producer :: [Input] -> FilePath -> State ()
producer c p = do
  liftIO $ Main.log "Starting producer"
  d <- asks done
  f <- liftIO $ readFile p
  mapM_ (\l -> mapM_
    (liftIO . flip writeChan l) c)
    $ zip [1..] $ map Just $ lines f
  liftIO $ modifyMVar_ d (return . not)

printer :: State ()
printer = do
  liftIO $ Main.log "Starting printer"
  c <- (fmap (map (snd . snd) . M.elems)
    (asks consumers >>= liftIO . readMVar))
  uniq' c
  where head' :: Output -> IO Line
    head' ch = fmap head (readMVar ch)

    tail' = mapM_ (liftIO . flip modifyMVar_
        (return . tail))

    cont ch = tail' ch >> uniq' ch

    printMsg ch = readMVar (head ch) >>=
        liftIO . putStrLn . fromJust . snd . head

    cempty :: [Output] -> IO Bool
    cempty ch = fmap (any id)
        (mapM (fmap ((==) 0 . length) . readMVar ) ch)

    {- Return false unless none are Nothing -}
    uniq :: [Output] -> IO Bool
    uniq ch = fmap (any id . map (isNothing . snd))
        (mapM (liftIO . head') ch)

    uniq' :: [Output] -> State ()
    uniq' ch = do
      d <- consumersDone
      e <- liftIO $ cempty ch
      if not e
        then  do
          u <- liftIO $ uniq ch
          if u then cont ch else do
        liftIO $ printMsg ch
        cont ch
          else unless d $ uniq' ch

1 个答案:

答案 0 :(得分:6)

并发编程不提供任何已定义的执行顺序,除非您自己使用mvar等强制执行。因此,在任何消费者将其读取并传递之前,生产者线程可能会将所有/大部分线路粘贴在chan中。另一个符合要求的架构就是让线程A调用惰性读取文件并将结果粘贴到mvar中。然后每个消费者线程获取mvar,读取一行,然后在继续处理该行之前替换mvar。即使这样,如果输出线程无法跟上,那么存储在chan上的匹配行数可以随意增加。

你拥有推送架构。要真正使其在恒定的空间中工作,请考虑需求驱动。找到一种机制,使输出线程向处理线程发出信号,表明它们应该做某事,并且处理线程向读者线程发出信号,告诉他们应该做什么。

另一种方法是让chans的大小有限 - 所以当处理器线程没有赶上时,读者线程会阻塞,因此当输出线程没有赶上时,处理器线程就会阻塞。 / p>

总的来说,这个问题实际上让我想起了Tim Bray的宽边基准,虽然要求有所不同。无论如何,它引发了关于实现多核grep的最佳方式的广泛讨论。最重要的是,问题是IO绑定,并且您希望多个读取器线程超过mmapped文件。

请参阅此处了解更多您想知道的内容:http://www.tbray.org/ongoing/When/200x/2007/09/20/Wide-Finder