Форум: "Прочее";
Текущий архив: 2009.02.22;
Скачать: [xml.tar.bz2];
ВнизНа что заменить критические секции в Vista? Найти похожие ветки
← →
Добежал (2008-12-18 17:38) [0]Имеем я так подозреваю стандартную задачу: некий поток выполняет работу. Работа эта описана в конкретных последовательных задачах, которые ему "присылаюся" извне. Ну допустим структура аля:
PTask = ^TTask;
TTask = record
Action: TActionProcedure;
Data: TData;
end;
Представим, что такого типа записи хранятся в некоем списке List.
Что делает поток? Из этого списка выбирает задания и основываясь на Action и Data что-то там делает. Потом выбирает следующее задание, выполняет его... И так далее, и так далее.
Чтобы добавить задание - нужно внести в этот список новую запись, ну понятно.
Остается вопрос синхронизации. Логично сделать этот список обычным TThreadList, ну или в целом синхронизировать с помощью критических секций. Но тут нас ожидает дикая засада в операционной системе Vista (заводил об этом тему здесь уже). Там изменили, "оптимизировали" критический секции, и так получается, что если поток активно работает со списком - то внешний поток, желающий добавить задание в этот список - может ждать невероятно долго. Рабочий поток может успеть СОТНИ раз (по времени это десятки секунд) войти и выйти в критическую секцию, синхронизирующую этот список, а внешний поток так и будет на ней висеть. То есть, в Vista полностью сняли принцип "первый в очереди - первый прошел" с критических секций (если такой принцип вообще был).
А в действительности требования наоборот, внешний поток задающий задачи должен по возможности отрабатывать наиболее быстро - поставил задание и свалил. Он это задание может раз в полчаса ставить, но отрабатывать должен быстро. А в итоге он отрабатывать может минуту (в висте, все что ниже задержка не более секунды), непредсказуемо ожидая момента разрешения входа в критическую секцию (повторюсь, в то время когда рабочий поток сотни раз из этой секции выходит и входит).
Вопрос - а что собственно делать для реализации сего действия? Сейчас я отказался от критических секций, сделал так сказать TThreadList, но основанный не на критичских секциях, а на Event"ах - там принцип "первый - первый" - видимо, пока поддерживается. Правильно ли я сделал? Какая гарантия, что в будущем MS отменит этот принцип и для Event"ов?
Как правильно реализовать задачу?
← →
Пробегал2.... (2008-12-18 21:34) [1]ау ;(
← →
Игорь Шевченко © (2008-12-18 21:57) [2]
> А в действительности требования наоборот, внешний поток
> задающий задачи должен по возможности отрабатывать наиболее
> быстро - поставил задание и свалил. Он это задание может
> раз в полчаса ставить, но отрабатывать должен быстро. А
> в итоге он отрабатывать может минуту (в висте, все что ниже
> задержка не более секунды), непредсказуемо ожидая момента
> разрешения входа в критическую секцию (повторюсь, в то время
> когда рабочий поток сотни раз из этой секции выходит и входит).
>
Тогда ему нужен всего лишь повышенный приоритет
← →
Пробегал2.... (2008-12-18 22:15) [3]Игорь Шевченко © (18.12.08 21:57) [2]
хм... что-то начинает мне казаться, что я тупой ;) Действительно, ведь есть приоритеты...
Я почему-то никогда не задумывался в этом аспекте. Рассуждал о приоритетах потока в смысле конкуренции с потоками других приложений (допустим, логично, что у explorer повышенный приоритет). Но ведь приоритетом потоков можно и в одном приложении вопросы разруливать... Надо попробовать, я как-то делал тестовую прогу, которая на висте фантастику выдавало (один поток не мог секунд 70 зайти в критическую секцию, когда второй поток сотни раз за это время входил и выходил). Как попробую - отпишусь.
← →
Пробегал2.... (2008-12-18 22:17) [4]Игорь, а вы вообще в теме насчет оптимизации крит. секций в Vista? Я так понимаю, что раньше была логика кто первый "завис" над критической секцией - тот первый и войдет в нее после освобождения. А в Vista изменили принцип.
Я правильно понимаю или не так немножко все? А у каких объектов вообще какие принципы? У мьютексов как я заметил все осталось по-прежнему, первый застолбил - первый пройдешь. А как насчет семафоров, event"ов и прочего, интересно просто...
← →
Игорь Шевченко © (2008-12-18 22:34) [5]
> а вы вообще в теме насчет оптимизации крит. секций в Vista?
В теме.
"Starting with Windows Server 2003 with Service Pack 1 (SP1), threads waiting on a critical section do not acquire the critical section on a first-come, first-serve basis. This change increases performance significantly for most code. However, some applications depend on FIFO ordering and may perform poorly or not at all on current versions of Windows (for example, applications that have been using critical sections as a rate-limiter). To ensure that your code continues to work correctly, you may need to add an additional level of synchronization. For example, suppose you have a producer thread and a consumer thread that are using a critical section object to synchronize their work. Create two event objects, one for each thread to use to signal that it is ready for the other thread to proceed. The consumer thread will wait for the producer to signal its event before entering the critical section, and the producer thread will wait for the consumer thread to signal its event before entering the critical section. After each thread leaves the critical section, it signals its event to release the other thread.
Windows Server 2003 and Windows XP/2000: Threads that are waiting on a critical section are added to a wait queue; they are woken and generally acquire the critical section in the order in which they were added to the queue. However, if threads are added to this queue at a fast enough rate, performance can be degraded because of the time it takes to awaken each waiting thread."
← →
Добежал (2008-12-19 11:07) [6]то есть, для всех объектов ядра, предназначенных для синхронизации действует правило FIFO, кроме критических секций?
← →
Riply © (2008-12-19 11:43) [7]> [0] Добежал (18.12.08 17:38)
> То есть, в Vista полностью сняли принцип "первый в очереди - первый прошел"
> с критических секций (если такой принцип вообще был).
> [4] Пробегал2.... (18.12.08 22:17)
> Я так понимаю, что раньше была логика кто первый "завис" над критической секцией
> - тот первый и войдет в нее после освобождения. А в Vista изменили принцип.
> У мьютексов как я заметил все осталось по-прежнему, первый застолбил - первый пройдешь.
> А как насчет семафоров, event"ов и прочего, интересно просто...
> [6] Добежал (19.12.08 11:07)
> то есть, для всех объектов ядра, предназначенных для синхронизации действует правило FIFO,
> кроме критических секций?
Его (принципа) никогда и не было:
"Тут возникает интересный вопрос. Если несколько потоков ждет один объект ядра, какой из них пробудится при освобождении этого объекта? Официально Microsoft отвечает на этот вопрос так: «Алгоритм действует честно" Что это за алгоритм, Micro soft не говорит, потому что нс хочст связывать себя обязательствами всегда придер живаться именно этого алгоритма. Она утверждает лишь одно- если объект ожидает ся несколькими потоками, то всякий раз, когда этот объект переходит в свободное состояние, каждый из них получает шанс на пробуждение.
Таким образом, приоритет потока не имеет значения- поток с самым высоким приоритетом не обязательно первым захватит объект. Не получает преимущества и поток, который ждал дольше всех. Есть даже вероятность, что какой-то поток сумеет повторно захватить объект. Конечно, это было бы нечестно по отношению к другим потокам, и алгоритм пытается не допустить этого. Но никаких гарантий нет.
На самом деле этот алгоритм просто использует популярную схему "первым во шел — первым вышел" (FIFO). B принципе, объект захватывается потоком, ждавшим дольше всех. Но в системе могут произойти какие-то события, которые повлияют на окончательное решение, и ил-за этого алгоритм становится менее предсказуемым. Вот почему Microsoft и не хочет говорить, как именно он работает. Одно из таких собы тий — приостановка какого-либо потока. Если поток ждет объект и вдруг приоста навливается, система просто забывает, что он ждал этот объект. А причина в том, что нет смысла планировать приостановленный поток. Когда он в конце концов возоб новляется, система считает, что он только что начал ждать данный объект.
Учитывайте это при отладке, поскольку в точках прерывания (breakpoints) все потоки внутри отлаживаемого процесса приостанавливаются. Отладка делает алго ритм FIFO в высшей степени непредсказуемым из-за частых приостановки и возоб новления потоков процесса." (с) Рихтер
← →
Добежал (2008-12-19 11:47) [8]
> Его (принципа) никогда и не было:
потрясающий у тебя вывод, Riply. И далее по тексту ты сама же цитируешь:
> На самом деле этот алгоритм просто использует популярную
> схему "первым во шел — первым вышел" (FIFO).
← →
Skyle © (2008-12-19 11:48) [9]
> Добежал (19.12.08 11:47) [8]
А дальше ты читал?
← →
Добежал (2008-12-19 11:50) [10]Но очевидно Рихтер все это писал до Vista. В ней алгоритм то как раз изменили, и принцип FIFO для критических секций более не действует. Riply, ты мне кажется не совсем въехала о чем мы говорим.
> Есть даже вероятность, что какой-то поток сумеет повторно
> захватить объект. Конечно, это было бы нечестно по отношению
> к другим потокам, и алгоритм пытается не допустить этого
в Vista как раз алгоритм вполне допускает это. Я уже говорили несколько раз, можно добиться что некий поток перезахватывает критическую секцию более СОТНИ раз в то время, как второй поток все это время ждет входа.
← →
Riply © (2008-12-19 11:50) [11]> [8] Добежал (19.12.08 11:47)
> потрясающий у тебя вывод, Riply. И далее по тексту ты сама же цитируешь:
А может сначала дочитать цитату, а потом удивляться моим выводам ? :)
← →
Riply © (2008-12-19 11:53) [12]> [10] Добежал (19.12.08 11:50)
> Но очевидно Рихтер все это писал до Vista. В ней алгоритм то как раз изменили,
> и принцип FIFO для критических секций более не действует. Riply,
> ты мне кажется не совсем въехала о чем мы говорим.
Ripyl "въехала". И то что в Виста все осталось примерно так-же
доказывает твоя педыдущая ветка (на которую ты ссылаешся) :)
← →
KSergey © (2008-12-19 11:54) [13]> Skyle © (19.12.08 11:48) [9]
> А дальше ты читал?
Я бы сказал - до :)
← →
Добежал (2008-12-19 11:54) [14]
> А дальше ты читал?
а ты читала? Рихтер прямым текстом говорит, что используется алгоритм FIFO. Естественно, с учетом других факторов. А ты говоришь, что там никакого FIFO не было никогда.
Вот в Vista FIFO для крит. секций отменили - это да, это факт. И это нагляднейше видно по работоспособности программы. На XP у меня интерфейс никогда не зависал, на Vista мог подвиснуть на минуту.
← →
Skyle © (2008-12-19 11:55) [15]
> Добежал (19.12.08 11:54) [14]
Ты промазал. Да, я читал.
> KSergey © (19.12.08 11:54) [13]
Ньюансы, оттенки смысла :)
← →
Добежал (2008-12-19 11:56) [16]
> И то что в Виста все осталось примерно так-же
надоело. Riply, прочитай хотя бы [5] а? Да, в висте все осталось по прежнему, именно поэтому microsoft пишет об изменениях.
← →
Добежал (2008-12-19 12:00) [17]ну а точнее MS пишет об изменениях не в висте, а в NT линейке начиная с Windows Server 2003. Просто я столкнулся с этим именно на Vista. Алгоритм который НИКОГДА не приводил к зависаниям интерфейса хотя бы на секунду, в Vista стандартно вешался на минуту и более.
Да, да, в vista ничего не изменили. Именно об этом и пишет MS, что начиная с Windows Server 2003 они ничего не меняли. Там на тарабарском языке именно так и написано.
← →
Тын-Дын © (2008-12-19 13:28) [18]
> Да, да, в vista ничего не изменили. Именно об этом и пишет
> MS, что начиная с Windows Server 2003 они ничего не меняли.
> Там на тарабарском языке именно так и написано.
Почему я не заметил отличий?
У меня одни и те же программы работают как на XP, так и на W2003, и на Vista.
← →
Игорь Шевченко © (2008-12-19 14:04) [19]При диспетчеризации потоков, ожидающих освобождения объектов синхронизации ядра происходит обслуживание по принципу очередей с приоритетами. Детали реализации этого обслуживания зависят от версии операционной системы. Приоритет потоков может измениться в любой момент, как в сторону понижения, так и в сторону повышения, в том числе он может измениться при самой диспетчеризации.
Что происходит с критическими секциями, написано в [5] - это цитата из MSDN
← →
Городской Шаман (2008-12-19 14:10) [20]
> Добежал (18.12.08 17:38)
А Sleep(0) между итерациями цикла не помогает?
← →
Добежал (2008-12-19 14:18) [21]
> А Sleep(0) между итерациями цикла не помогает?
помогает, ведь это приводит к переключению активного потока.
Но мне почему-то кажется, что Sleep - это идеологически неверное решение. Хотя решение.
← →
oxffff © (2008-12-19 14:22) [22]??
//by oxffff aka Sergey Antonov
TAbstractLOCK=class
public
function TRYLOCK:integer;virtual;abstract;
procedure LOCK;virtual;abstract;
procedure UNLOCK;virtual;abstract;
end;
TSPINLOCK=class(TAbstractLOCK)
protected
lSynchronizeInt:integer;
public
constructor create;
function TRYLOCK:integer;override;
procedure LOCK;override;
procedure UNLOCK;override;
end;
constructor TSPINLOCK.create;
begin
lSynchronizeInt:=RESOURCE_FREE;
end;
function TSPINLOCK.TRYLOCK:integer;
begin
case InterlockedExchange(lSynchronizeInt,RESOURCE_LOCKED) of
RESOURCE_FREE:result:=CONST_OK;
else result:=CONST_NOT;
end;
end;
procedure TSPINLOCK.LOCK;
begin
while InterlockedExchange(lSynchronizeInt,RESOURCE_LOCKED)=RESOURCE_LOCKED do;
end;
procedure TSPINLOCK.UNLOCK;
begin
InterlockedExchange(lSynchronizeInt,RESOURCE_FREE);
end;
{ TSmartObject }
← →
oxffff © (2008-12-19 14:23) [23]CONST
RESOURCE_FREE=0;
RESOURCE_LOCKED=1;
← →
Добежал (2008-12-19 14:24) [24]попытаюсь объяснить, почему так считаю. Ведь Sleep(x) это комманда, которая говорит диспетчеру потоков, что потоку не нужно процесорное время еще x миллисекунд. Все пользуются тем, что sleep(0) приводит к переключению контекста, но ведь это я думаю нигде не запротоколировано. Поэтому не совсем верно так писать.
Плюс это замедляет выполнение алгоритма, мы фактически гарантируем, что на одно выделение кванта времени будет исполнено максимум одна итерация цикла. И хотя в реальности хрен кто заметит разницы скорее всего, но тем не менее имхо так писать не идеально. Поэтому и хочется проработать этот вариант, сделать как реально правильно - и в дальнейшем всегда так и делать.
← →
oxffff © (2008-12-19 14:25) [25]Еще есть же Interlocked Singly Linked Lists с тем же механизмом.
← →
oxffff © (2008-12-19 14:27) [26]
> Добежал (19.12.08 14:24) [24]
Используй spinlock так называют его в режиме ядра.
Но смысл крутиться в цикле с постоянным опросом.
← →
Добежал (2008-12-19 14:37) [27]
> oxffff
да, думал о таком. Но алгоритм думаю нужно доработать так, как доработали критические секции в w2k. То есть что-то типа:TAbstractLOCK=class
public
FCountRepeat: integer;
FSyncEvent: THandle; // на случай долгого ожидания синхронизирующий эвент
...procedure TSPINLOCK.LOCK;
var
iCount: integer;
bLocked: boolean;
begin
iCount := 0;
bLocked := false;
while InterlockedExchange(lSynchronizeInt,RESOURCE_LOCKED) =RESOURCE_LOCKED do
begin
inc(iCount);
if iCount > FCountRepeat then
begin
WaitForSingleObject(FSyncEvent, INFINITE);
bLocked := true;
end
else Sleep(0);
end;
if not bLocked then WaitForSingleObject(FSyncEvent, INFINITE);
end;
то есть, такой симбиоз. И в каждом конкретном случае надо просто грамотно выбрать FCountRepeat
← →
Добежал (2008-12-19 14:41) [28]блин, написал я конечно не очень рабочий алгоритм. Ну думаю смысл понятен - также как оптимизировали критические секции в w2k. Чтобы сначала некоторое время поток без ухода в режим ядра пытался "пробиться", ну а потом уже если ожиданеи долгое - заснул. Тогда получиться универсальный алгоритм.
← →
oxffff © (2008-12-19 14:45) [29]
> Добежал (19.12.08 14:37) [27]
Смысл spinlock как раз состоит в том, что ожидание предполагается, что ожидание минимально.
А работа со списком как раз это предполагает.
Я думаю проверка лишняя при очень быстрых доступах.
> inc(iCount);
> if iCount > FCountRepeat then
> begin
> WaitForSingleObject(FSyncEvent, INFINITE);
> bLocked := true;
> end
> else Sleep(0);
> end;
> if not bLocked then WaitForSingleObject(FSyncEvent, INFINITE);
>
← →
Игорь Шевченко © (2008-12-19 14:45) [30]
> Ведь Sleep(x) это комманда, которая говорит диспетчеру потоков,
> что потоку не нужно процесорное время еще x миллисекунд.
>
Sleep приводит к ожиданию потока на объекте ядра "таймер". В случае интервала таймера равного нулю, таймер просто срабатывает мгновенно, но срабатывает весь механизм диспетчеризации потоков. Поэтому после sleep(0) поток может продолжать выполняться, как ни в чем не бывало, без переключения на другие потоки
← →
oxffff © (2008-12-19 14:47) [31]
> Добежал (19.12.08 14:41) [28]
Есть даже такая функция.
InitializeCriticalSectionAndSpinCount
← →
Добежал (2008-12-19 14:55) [32]
> InitializeCriticalSectionAndSpinCount
верно, я про нее и говорю. Но появилась она только в w2k.
> Я думаю проверка лишняя при очень быстрых доступах
ну при очень быстрых доступах до ухода в режим ядра и не дойдет. А уж проверка "if a > b" можно считать вообще не отнимает процессорное время по сравнению с остальным.
Впрочем, данная реализация не очень хороша...
> Sleep приводит к ожиданию потока на объекте ядра "таймер".
>
хм.. Логично... То есть, функция Sleep приводит к переключению в режим ядра со всеми вытекающими процессорными затратами, верно?
← →
oxffff © (2008-12-19 14:57) [33]
> Добежал (19.12.08 14:55) [32]
У тебя работа связана с андронным коллайдером?
Думаешь он поэтому не работает?
:)
← →
KSergey © (2008-12-19 15:03) [34]> Skyle © (19.12.08 11:55) [15]
> Ньюансы, оттенки смысла :)
Я имел ввиду не "дочитал", а то, что до указанного места говорится как оно по документации, а потом - как реализовали это в MS.
Беда в том, что и я при чтении этого места всегда описанную реализацию принимал за аксиому, и лишь Рипли - спасибо ей - надоумила своей цитатой меня на то, что далее второго из процитированных абзацев читать и вовсе не стоит. Лишь для расширения кругозора...
← →
Добежал (2008-12-19 15:03) [35]не :)
Я пытаюсь сделать "идеальную" реализацию TThreadList. Сделать ее и забыть, всегда пользуясь шаблоном. До недавних пор я пользовался самим TThreadList и был доволен, но в Vista напоролся на безумство в виде того, что один поток сотни раз входит и выходит из критической секции, в то время как другой поток минуту висит над этой критической секцией.
Вот думаю...
> При диспетчеризации потоков, ожидающих освобождения объектов
> синхронизации ядра происходит обслуживание по принципу очередей
> с приоритетами
Игорь, вы уверены? У меня есть ощущение, что работает все таки принцип FIFO, то есть если уж поток первым добрался до Wait функции, то он первым и "проскочит". Окромя исключения в виде критический секций, начиная с w2003s
← →
Игорь Шевченко © (2008-12-19 15:04) [36]
> Игорь, вы уверены?
Да
← →
Игорь Шевченко © (2008-12-19 15:04) [37]Удалено модератором
Примечание: Дубль
← →
KSergey © (2008-12-19 15:06) [38]> Добежал (19.12.08 14:55) [32]
>
> > InitializeCriticalSectionAndSpinCount
>
>
> верно, я про нее и говорю. Но появилась она только в w2k.
>
Вот. Это ка краз говорит о том, что есть большой смысл сделать 2 разных реализации: для 9x/NT4 и 2000 и далее. Разруливать в ран-тайм созданием объекта правильного для текущей ОС класса.
← →
Riply © (2008-12-19 16:57) [39]Это код:
var
GlobalThredID: ULONG = 0;
GlobalCount: integer = 0;
type
PTHREAD_CS = ^THREAD_CS;
THREAD_CS = packed record
pCS: PRTL_CRITICAL_SECTION;
Iterations: integer;
ThreadID: THANDLE;
aCount: integer;
_Stuff: ULONG;
end;
THREADS_ARRAY = array of THREAD_CS;
function ThreadFunction(pThreadCS: Pointer): integer;
var
i: integer;
begin
Result := 0;
for i := 0 to Pred(PTHREAD_CS(pThreadCS).Iterations) do
begin
RtlEnterCriticalSection(PTHREAD_CS(pThreadCS).pCS);
try
if i = 0 then
begin
inc(GlobalCount);
Log_WriteMessageNt("Start", "Step: " + IntToStr(i) + " ID: " + IntToStr(GlobalThredID) + " ActiveThreads: " + IntToStr(GlobalCount), STATUS_SUCCESS);
end;
if GlobalCount = PTHREAD_CS(pThreadCS).aCount then
if GlobalThredID = PTHREAD_CS(pThreadCS).ThreadID
then Log_WriteMessageNt("Break FIFO", "Step: " + IntToStr(i) + " ID: " + IntToStr(GlobalThredID) + " ActiveThreads: " + IntToStr(GlobalCount), STATUS_SUCCESS);
GlobalThredID := PTHREAD_CS(pThreadCS).ThreadID;
if i = Pred(PTHREAD_CS(pThreadCS).Iterations) then
begin
Log_WriteMessageNt("Stop", "Step: " + IntToStr(i) + " ID: " + IntToStr(GlobalThredID) + " ActiveThreads: " + IntToStr(GlobalCount), STATUS_SUCCESS);
Dec(GlobalCount);
end;
finally
RtlLeaveCriticalSection(PTHREAD_CS(pThreadCS).pCS);
end;
end;
end;
procedure TMainForm.btnTest_2Click(Sender: TObject);
var
ThreadCS: RTL_CRITICAL_SECTION;
i, ThreadsCount, IterationCount: integer;
RetStatus: NTSTATUS;
ThreadID: ULONG;
ParamsArr: THREADS_ARRAY;
ThreadsArr: array of THANDLE;
begin
inherited;
RetStatus := RtlInitializeCriticalSection(@ThreadCS);
if NT_SUCCESS(RetStatus) then
try
ThreadsCount := 3;
IterationCount := 10000;
SetLength(ThreadsArr, ThreadsCount);
SetLength(ParamsArr, ThreadsCount);
try
for i := 0 to Pred(ThreadsCount) do
with ParamsArr[i] do
begin
pCS := @ThreadCS;
Iterations := IterationCount;
aCount := ThreadsCount;
ThreadsArr[i] := BeginThread(nil, 0, ThreadFunction, @ParamsArr[i], CREATE_SUSPENDED, ThreadID);
end;
for i := 0 to Pred(ThreadsCount) do ResumeThread(ThreadsArr[i]);
WaitForMultipleObjects(ThreadsCount, @ThreadsArr[0], True, INFINITE);
finally
for i := 0 to Pred(ThreadsCount) do CloseHandle(ThreadsArr[i]);
end;
finally
RtlDeleteCriticalSection(@ThreadCS);
end;
MessBox_Inf("End of work");
end;
← →
Riply © (2008-12-19 17:01) [40]Это лог:
0000003628 19.12 16:44:27.640 Start Step: 0 ID: 0 ActiveThreads: 1 The operation completed successfully 0000000001 0000000863
0000003864 19.12 16:44:27.640 Start Step: 0 ID: 3628 ActiveThreads: 2 The operation completed successfully 0000000002 0000000864
0000003952 19.12 16:44:27.640 Start Step: 0 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000003 0000000865
0000003864 19.12 16:44:27.656 Break FIFO Step: 355 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000004 0000000866
0000003952 19.12 16:44:27.671 Break FIFO Step: 1106 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000005 0000000867
0000003952 19.12 16:44:27.671 Break FIFO Step: 1107 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000006 0000000868
0000003628 19.12 16:44:27.671 Break FIFO Step: 2070 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000007 0000000869
0000003864 19.12 16:44:27.671 Break FIFO Step: 1959 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000008 0000000870
0000003864 19.12 16:44:27.671 Break FIFO Step: 1960 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000009 0000000871
0000003864 19.12 16:44:27.671 Break FIFO Step: 1961 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000010 0000000872
0000003864 19.12 16:44:27.671 Break FIFO Step: 1962 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000011 0000000873
0000003864 19.12 16:44:27.671 Break FIFO Step: 1963 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000012 0000000874
0000003864 19.12 16:44:27.671 Break FIFO Step: 1964 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000013 0000000875
0000003864 19.12 16:44:27.671 Break FIFO Step: 1965 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000014 0000000876
0000003864 19.12 16:44:27.671 Break FIFO Step: 1966 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000015 0000000877
0000003864 19.12 16:44:27.671 Break FIFO Step: 1967 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000016 0000000878
0000003864 19.12 16:44:27.671 Break FIFO Step: 1968 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000017 0000000879
0000003864 19.12 16:44:27.671 Break FIFO Step: 1969 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000018 0000000880
0000003864 19.12 16:44:27.671 Break FIFO Step: 1970 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000019 0000000881
0000003864 19.12 16:44:27.671 Break FIFO Step: 1971 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000020 0000000882
0000003864 19.12 16:44:27.671 Break FIFO Step: 1972 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000021 0000000883
0000003864 19.12 16:44:27.671 Break FIFO Step: 1973 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000022 0000000884
0000003864 19.12 16:44:27.671 Break FIFO Step: 1974 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000023 0000000885
0000003864 19.12 16:44:27.671 Break FIFO Step: 1975 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000024 0000000886
0000003864 19.12 16:44:27.671 Break FIFO Step: 1976 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000025 0000000887
0000003864 19.12 16:44:27.671 Break FIFO Step: 1977 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000026 0000000888
0000003628 19.12 16:44:27.703 Break FIFO Step: 3599 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000027 0000000889
0000003628 19.12 16:44:27.703 Break FIFO Step: 3600 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000028 0000000890
0000003628 19.12 16:44:27.703 Break FIFO Step: 3601 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000029 0000000891
0000003628 19.12 16:44:27.703 Break FIFO Step: 3602 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000030 0000000892
0000003628 19.12 16:44:27.703 Break FIFO Step: 3603 ID: 3628 ActiveThreads: 3 The operation completed successfully 0000000031 0000000893
0000003864 19.12 16:44:27.703 Break FIFO Step: 3638 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000032 0000000894
0000003952 19.12 16:44:27.718 Break FIFO Step: 4495 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000033 0000000895
0000003952 19.12 16:44:27.718 Break FIFO Step: 4497 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000034 0000000896
0000003952 19.12 16:44:27.718 Break FIFO Step: 4498 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000035 0000000897
0000003952 19.12 16:44:27.718 Break FIFO Step: 4499 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000036 0000000898
0000003952 19.12 16:44:27.718 Break FIFO Step: 4500 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000037 0000000899
0000003952 19.12 16:44:27.718 Break FIFO Step: 4501 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000038 0000000900
0000003952 19.12 16:44:27.718 Break FIFO Step: 4502 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000039 0000000901
0000003952 19.12 16:44:27.718 Break FIFO Step: 4503 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000040 0000000902
0000003952 19.12 16:44:27.718 Break FIFO Step: 4504 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000041 0000000903
0000003952 19.12 16:44:27.718 Break FIFO Step: 4505 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000042 0000000904
0000003952 19.12 16:44:27.718 Break FIFO Step: 4506 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000043 0000000905
0000003952 19.12 16:44:27.718 Break FIFO Step: 4507 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000044 0000000906
0000003864 19.12 16:44:27.718 Break FIFO Step: 4778 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000045 0000000907
0000003864 19.12 16:44:27.718 Break FIFO Step: 4779 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000046 0000000908
0000003864 19.12 16:44:27.734 Break FIFO Step: 5168 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000047 0000000909
0000003864 19.12 16:44:27.734 Break FIFO Step: 5169 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000048 0000000910
0000003952 19.12 16:44:27.765 Break FIFO Step: 7894 ID: 3952 ActiveThreads: 3 The operation completed successfully 0000000049 0000000911
0000003864 19.12 16:44:27.796 Break FIFO Step: 9287 ID: 3864 ActiveThreads: 3 The operation completed successfully 0000000050 0000000912
0000003864 19.12 16:44:27.796 Break
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2009.02.22;
Скачать: [xml.tar.bz2];
Память: 0.61 MB
Время: 0.006 c