Last couple update to fpc 2.1.1 for Darwin have been broken

Here are some symptom:

At times XCode debugger stops program/trace with SIGSEGV TThread creation seems about 10 times faster.
Sleep( 1 ) does not sleep for one milli-second, more llike 0. There may be inconsistent results with critical sections.

Will try to get more useful results soon.

P Davidson
Corax Networks Inc.
http://CoraxNetworks.com

Debugging info in 2.1.1 is currently broken on all platforms.

TThread creation seems about 10 times faster.

Don't know what changed here.

Jonas

This is a known issue, the debuginfo is broken. I'm busy with fixing this, but i don't have much time.

On 11 okt 2005, at 13:11, Paul Davidson wrote: Don't know what changed here.

The sleep was changed from select to nanosleep. It seems OS X doesn't accept sleeps smaller than 10ms. Maybe revert to select() for Mac OS X only?

(the select breaks Kylix compat on Linux)

Marco van de Voort wrote

The sleep was changed from select to nanosleep. It seems OS X doesn't accept sleeps smaller than 10ms.

That is not true. This program takes half a second on my machine:

#include <time.h>
int main() {
   struct timespec t1;
   int i;
   t1.tv_sec = 0;
   t1.tv_nsec = 5*1000*1000;
   for (i = 0; i < 100; i++) {
     nanosleep(&t1,NULL);
   }
}

Jonas

Jonas Maebe wrote

> TThread creation seems about 10 times faster. Don't know what changed here.

Looking at RTL, Threads are now using semaphores instead of pipes for suspend/resume.
This may be reason for increased speed.

P Davidson

Lets wait for debug to return before making any changes. Will investigate further at that time

P Davidson

Odd then. There was a problem with threadshutdown that went away around 10ms. Will test some more then.

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 kind of precision is achieved throught other means, such as special device drivers, interruptions, real-mode, etc.

This happens for all protected-mode operating systems, but is worse on linux due to the fair way the thread manager alocates time for each task. On Windows this is not so bad because it doesn't distribute as fairly the time.

This problem does not exist on real-mode OSes, such as DOS.

Take a look at: http://www.linuxjournal.com/article/0232

and: http://www.geisswerks.com/ryan/FAQS/timing.html

You're completely right they are not reliable. Also, you must always remember that nanosleep() can return before it has waited for the specified time (that's what the second parameter is for) because of delivery of a signal.

Jonas

Tested some sleep and nano sleep functions.
They seems to work well, given the limits of Darwin OS.

Now tracking possible suspend/resume issues.

P Davidson

Paul Davidson wrote

Tested some sleep and nano sleep functions. They seems to work well, given the limits of Darwin OS.

Not sure what limits you mean. Darwin has one of the smallest scheduling latencies of all non-real time OS'es out there. Try running "sudo latency -rt" for a while.

Jonas

Tests where with app that monitors to at least mS intervals. Results are consistent with past runs. Altering internal fixed delays of +/- 1 mS reported acceptable results.

P Davidson
Corax Networks Inc.
http://CoraxNetworks.com

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.

program project1;
{$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;
  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(False);
  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( '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.

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.

P Davidson