改进任务响应能力的建议

本文关键字:能力 响应 任务 | 更新日期: 2023-09-27 18:22:09

我有一个应用程序,它在4个不同的段中下载一个文件(每个段是不同的长期运行任务),并定期序列化进度。

当串行化发生在2核机器上时,进程将阻塞3-10秒,然后完成。一旦这种阻塞行为第一次发生,就再也不会发生了。第二个到(n)的调用立即串行化执行,没有任何问题。似乎在第一次调用阻塞期间,框架进行了一些任务/线程优化,以防止阻塞行为形式再次发生。

有人了解这种优化吗?是否可以在初始化时进行这种类型的优化,以避免阻塞行为?

这里有一些伪代码来帮助描述这种情况:

class Download
{
    private DownloadSegment[] _downloadSegments = new DownloadSegment[4];
    public void StartDownload()
    {
        for (int i = 0; i < 4; i++)
        {
            _downloadSegments[i] = new DownloadSegment();
            _downloadSegments[i].Start();
        }
    }
    public void Serialize()
    {
        try
        {        
            //enter lock so the code does not serilize the progress while 
            //writing new downloaded info at the same time
            foreach(DownloadSegment segment in _downloadSegments)
            {
                Monitor.Enter(segment.SyncRoot);
            }
            //code to serialize the progress
        }
        finally
        {
            foreach (DownloadSegment segment in _downloadSegments)
            {
                Monitor.Exit(segment.SyncRoot);
            }
        }
    }
}
class DownloadSegment
{
    public object SyncRoot = new object();
    public void Start()
    {
        Task downloadTask = new Task(
            () =>
                {
                    //download code
                    lock (SyncRoot)
                    {
                        //wirte to disk code
                    }                        
                },
        new CancellationToken(),
        TaskCreationOptions.LongRunning);
        downloadTask.Start(TaskScheduler.Default);
    }
}

改进任务响应能力的建议

感谢您的建议usr。原来是文件流写入导致了问题。

事实证明,当你使用FileStream.SetLength()为一个大文件分配文件空间,然后寻找该文件深处的一个部分时,一旦你开始在文件中的那个位置写入,稀疏的文件空间就会被"回填",这可能会很慢。我在代码中的锁只是通过让未阻塞的段等待繁忙的段来暴露问题。

我将发布一个单独的问题,看看是否有更有效的方法来编写/创建这些文件。