Various Darwin problems

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Various Darwin problems

Paul Davidson
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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Jonas Maebe-2

On 11 okt 2005, at 13:11, Paul Davidson wrote:

> 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

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Peter Vreman
In reply to this post by Paul Davidson
> 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

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



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Marco van de Voort
In reply to this post by Jonas Maebe-2
> 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)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Jonas Maebe-2

On 11 okt 2005, at 13:46, 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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Paul Davidson
In reply to this post by Jonas Maebe-2

On Oct 11, 2005, at 7:18, 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.

>
>
> Jonas
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>
P Davidson

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Paul Davidson
In reply to this post by Marco van de Voort
Lets wait for debug to return before making any changes.
Will investigate further at that time

On Oct 11, 2005, at 7:46, Marco van de Voort wrote:

>> 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)
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>
P Davidson

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Marco van de Voort
In reply to this post by Jonas Maebe-2
> On 11 okt 2005, at 13:46, 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:

Odd then. There was a problem with threadshutdown that went away around
10ms. Will test some more then.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Felipe Monteiro de Carvalho
In reply to this post by Jonas Maebe-2
On 10/11/05, Jonas Maebe <[hidden email]> wrote:
> On 11 okt 2005, at 13:46, 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:

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

--
Felipe Monteiro de Carvalho
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Jonas Maebe-2

On 11 okt 2005, at 14:25, Felipe Monteiro de Carvalho 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:
>
> 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.

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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

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

Now tracking possible suspend/resume issues.

On Oct 11, 2005, at 8:35, Jonas Maebe wrote:

>
> On 11 okt 2005, at 14:25, Felipe Monteiro de Carvalho 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:
>>
>> 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.
>
> 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
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>
P Davidson

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Jonas Maebe-2

On 11 okt 2005, at 14:39, 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Paul Davidson
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.


On Oct 11, 2005, at 8:44, Jonas Maebe wrote:

>
> On 11 okt 2005, at 14:39, 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
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>
P Davidson
Corax Networks Inc.
http://CoraxNetworks.com

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Marco van de Voort
In reply to this post by Felipe Monteiro de Carvalho
> > > 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.

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.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Various Darwin problems

Paul Davidson
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  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal