Modified program by creating threads resumed (not suspended),
then using new loop to start each one.
Though new loop completes, and threads are created (31 inclucing
process),
they refuse to be terminated. It seems that RESUME, at least from
another thread, if faulty.
As well, CPU utilization is still near 100%
program TestResume;
{$mode objfpc}{$H+}
uses
cThreads, BaseUnix, Unix, Classes;
const
MAX = 30;
type
TThr = class(TThread)
protected
procedure Execute; override;
end;
var
ti1 : timeval;
ti2 : timeval;
tiz : timezone;
procedure TThr.Execute;
var
T1, T2: Ttimespec;
begin
T1.tv_sec:=0;
T1.tv_nsec:=1000;
Suspend;
while not Terminated do
FpNanoSleep(@T1, @T2);
end;
var
a: array[1..MAX] of TThr;
i: Integer;
T1, T2: Ttimespec;
begin
T1.tv_sec:=10;
T1.tv_nsec:=0;
// Set up time
fpGetTimeOfDay( @ti1, @tiz );
for i:=1 to MAX do
a[i]:=TThr.Create(TRUE);
fpGetTimeOfDay( @ti2, @tiz );
Writeln('Threads created in ',
( ( ( extended( ti2.tv_sec ) * 1000000 + ti2.tv_usec ) -
( extended( ti1.tv_sec ) * 1000000 + ti1.tv_usec ) ) / 1000 ):7:3,
'mS' );
writeln( 'Waking threads' );
fpGetTimeOfDay( @ti1, @tiz );
for i:=1 to MAX do
a[i].Resume;
fpGetTimeOfDay( @ti2, @tiz );
Writeln('Threads woke in ',
( ( ( extended( ti2.tv_sec ) * 1000000 + ti2.tv_usec ) -
( extended( ti1.tv_sec ) * 1000000 + ti1.tv_usec ) ) / 1000 ):7:3,
'mS' );
writeln( 'Waiting 10 seconds' );
FpNanoSleep(@T1, @T2);
Write('Freeing threads... ');
fpGetTimeOfDay( @ti1, @tiz );
for i:=1 to MAX do begin
a[i].Terminate;
a[i].WaitFor;
a[i].Free;
end;
fpGetTimeOfDay( @ti2, @tiz );
Writeln('Threads destroyed in ',
( ( ( extended( ti2.tv_sec ) * 1000000 + ti2.tv_usec ) -
( extended( ti1.tv_sec ) * 1000000 + ti1.tv_usec ) ) / 1000
):10:3, 'mS' );
Writeln('Done');
end.
On Oct 11, 2005, at 9:07, Marco van de Voort wrote:
doesn't accept
sleeps smaller than 10ms.
That is not true. This program takes half a second on my machine:
This only happens because you are getting a very big time period on
your test. Sleep, nanosleep and all other timing procedures are simply
*not* reliable when you want a microsecond or 1milisecond precision.
This is a general problem for preemptive OSes. I had problems with
Darwin
beyond that, iow magnitudes more than expected.
In the demo below for high values (100ms) in the thread.execute sleep,
threadshutdown
is swift (few hunderd ms). For short ones, it isn't (few sec).
P. Davidson came with the problem, Almindor with the test, and I could
duplicate the problem, but not explain it. Maybe the larger pauze
avoids
shutting all 30 threads at once, and is _that_ (30 threads shutting
down
at once) the problem.
P Davidson
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
