我有一个应用程序,它下载4个不同的段中的单个文件(每个段是一个不同的长时间运行的任务),并以定期间隔序列化进度。
当序列化在双核机器上发生时,进程将阻塞3-10秒,然后完成。一旦这种阻塞行为第一次发生,它就不会再发生了。第二个to (n)调用立即执行serialize,没有任何问题。似乎在第一次调用阻塞期间,框架做了一些任务/线程优化,以防止阻塞行为再次发生。
有没有人了解这种优化,以及是否有可能在初始化时进行这种类型的优化,以避免所有阻塞行为?
下面是一些伪代码来帮助描述这种情况:
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);
}
}发布于 2013-07-24 01:13:11
谢谢你的建议。事实证明,是文件流写入导致了问题。
事实证明,当您使用FileStream.SetLength()为一个大文件分配文件空间,然后查找该文件内部更深的部分时,一旦您在文件中的该位置开始写入,稀疏的文件空间将被“回填”,这可能会很慢。我在代码中的锁只是通过让未阻塞的段等待繁忙的段来暴露问题。
我将发布一个单独的问题,看看是否有更有效的方法来编写/创建这些文件。
https://stackoverflow.com/questions/17633472
复制相似问题