Hello,
I will try to clarify more this problem that i have solved in
version 2.16 ...
If you take a look inside the parallelcompression zipfile,
inside the file parallelgzip.pas, you will notice that i am using a threadpool
engine and inside the TCallbacks.GzipCompress() method i am using
GZCompressStream() outside the critical section , this is good for
scalability, but inside the same method i am using also a critical section
like this:
repeat
If TParallelGzip(Tjob(obj).obj).count_compress = Tjob(obj).index
then
begin
// i am using some code here
Inc(TParallelGzip(Tjob(obj).obj).count_compress);
break;
end;
sleep(0);
until false;
as you have noticed , in this critical section i am testing like this:
If TParallelGzip(Tjob(obj).obj).count_compress = Tjob(obj).index
and if you read carefully the code inside parallelgzip.pas you will
notice that since i am using a critical section like this , and using
a threadpool engine, the threadpool engine must not use work-sealing
or this will cause a deadlock inside the TCallbacks.GzipCompress() method,
so to correct this problem i had to use for example a FIFO queue for
each worker thread to enhance the scalability and completly avoid
work-stealing (from the LIFO Stacks.or FIFO Queues).
Thank you for your time.
Amine Moulay Ramdane.
Recent
