Hi,

I first asked this question in the Lazarus mailing list, but was told it may be more appropriate here. When you create a new project in Lazarus, the default uses clause in the *.lpr file looks as follows:

---------------
uses

  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes;

---------------

Question 1:
Is there an alternative implementation of multi-threading support for Unix-type systems -- other than the cthreads unit?

Question 2:
If not, then why do we have the extra "IFDEF UseCThreads" define in the uses clause?

Why can't we just have the following...? By default Windows programs and OS/2 programmes have multi-threading support compiled in, why don't we do the same for Unix-type systems? I often get the "program not compiled with multi-threading support" error and have to constantly define the UseCThreads option.

---------------
uses

  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}
  Classes;

---------------

Mattias mentioned that when cthreads unit is included, all string access needs critial sections which will slow down string access for any unix-type OS.

Now because under Windows, threading support is on by default, does that mean the same program will run faster under Linux than under Windows? Why is threading enabled by default under Windows and not under other platforms?

I asked Mattias for a sample project that will show the slowdown, so I can see by what factor it is slower. He supplied the following program.

---------------------
program bench1;
{$mode objfpc}{$H+}
uses
  //cthreads,
  //cmem,
  classes, sysutils;
var
  s1: String;
  s2: String;
  i: Integer;
  s: String;
  t: TThread;
begin
  //t:=TThread.Create(true);
  s1:=IntToStr(Paramcount+12345);
  s2:=IntToStr(Paramcount+23456);
  for i:=1 to 500000000 do begin
    s:=s1;
    s:=s2;
  end;
end.
---------------------

Mattias test results are as follows:

Under his Linux machine the above program takes about 7.5 seconds. Uncomment the cthreads unit: 7.5 seconds

Under OS X the above program takes on his mac book about 15 seconds. Uncomment the cthreads unit: 21 seconds

On my Linux system I have the following results:
// without cthreads in uses clause
$ time ./bench1

real 0m9.971s
user 0m9.969s
sys 0m0.004s

// with cthreads in uses clause - but no TThread usage.
$ time ./bench1

real 0m9.973s
user 0m9.973s
sys 0m0.000s

So on my system having the cthreads unit included by default will make no is the point I'm trying to make.

Can anybody explain why we have to explicitly enable threading support under unix-type OSes, but comes standard with Windows?

Regards,
- Graeme -

No.

To be able to disable it ?

Because it creates a dependency on the C library, which is not always wanted. For Lazarus programs, the dependency exists anyway, so it does not make a lot of sense to have the define.

Michael.

But surely that c library is available on all unix-type systems? To why is that dependency a bad thing?

Regards,
- Graeme -

2009/8/27 Graeme Geldenhuys :

The linux threading support is part of glibc. See `man pthreads`. That's why Mattias says that including it by default in lazarus is o.k., since all the widgetsets depend on libc, anyway.

Threading on Windows works with Windows API functions.

Henry

Because I want a FPC program to depend only on the Linux kernel, not on the C library.

There are FPC programs from 8 years back that still work with the current kernel. Try that with a program that depends on the C library.

Michael.

I understand all this, but isn't libc available on all unix-type OSes. If so, then I don't understand why it (threading) must be optional in FPC based applications.

Regards,
- Graeme -

Michael Van Canneyt wrote

Because I want a FPC program to depend only on the Linux kernel, not on the C library.

OK.

There are FPC programs from 8 years back that still work with the current kernel. Try that with a program that depends on the C library.

Sorry if this sounds dumb - it's late in the week. ;-) Is this an issue, even if your program doesn't use any procedures/functions from the dynamically linked C library. For example, a console application that includes the cthreads unit (which dynamically links to C Library), but doesn't actually use the C Library or threads. Would such a console application not run on an 8 year old Linux distro?

Regards,
- Graeme -

2009/8/27 Michael Van Canneyt :

The only reason for this is the fact that the rtl is compiled into fpc executables. If fpc had an rtl as a lib (like c), we would be in the same boat.

Henry

In our previous episode, Graeme Geldenhuys said:

Not.

Question 2: If not, then why do we have the extra "IFDEF UseCThreads" define in the uses clause?

In case you don't use threads and want to make a static binary.

Because the API model of Unix is totally different from Windows and OS/2.

I do think that if Lazarus has separate templates for "LCL app" and "general app" that the ifdef could disappear from the LCL app, since that is never static anyway.

No, because using cthreads overrides internal dummy callbacks by procedures linking against libc thus libc is linked in. Further, units like classes or the heap manager use internally critical sections so you really depend on libc if you link cthreads. If you don't include cthreads these callbacks/hooks are simply empty with the side effect that things are faster.

In our previous episode, Graeme Geldenhuys said:

There is not one C library. There are several. And all these are separately versioned, and can also be configured differently. (removing legacy symbols, enabling alpha functionality).

The problem is that Linux distro's seem to assume that all binaries are generated on the system they are used, and interpret the effective API of the system from the available headers.

To why is that dependency a bad thing?

It makes it very hard to longterm succesfully deploy a simple linux binary over several systems.

OS X and FreeBSD have basically the same problem, however has some mitigating factors (they change mostly only with major versions, and have the ability to run older binaries using resp COMPAT and SDK system)

2009/8/27 Graeme Geldenhuys :

I understand all this, but isn't libc available on all unix-type OSes.

In my limited experience, I haven't come across a linux system without some form of a c library. Pretty much everything in gnu userland relies on it.

If so, then I don't understand why it (threading) must be optional in FPC based applications.

Not depending on libc is a good thing and keeps options open, especially for embedded development. E.g. you can try and write your own busybox style program in fpc, to make a 100% pascal userland :)

Henry

It would not run *on* an 8-year old Linux distro regardless of whether you use libc, because FPC nowadays uses Linux 2.4.x+ system calls. What Michael was talking about was about running 8-year old programs on a current kernel.

And that would probably work, although with some caveats. Programs that use the C library also require special startup code. This code is normally in crt1.o and shipped together with the C library, and is always linked statically into the program. FPC contains its own version of that code for Linux and *BSD, but slightly adapted. There are different versions for at least libc5, glibc 2.x and uclibc (and they are not interchangeable).

The switchover from libc5 to glibc 2.x happened more than 8 years ago, so you'd probably be safe in this particular scenario.

Jonas

No, not really. A static (g)libc is often as well a problem because configurable options are taken from the host system and hard coded into the resulting libc.

In our previous episode, Graeme Geldenhuys said:

No. The init code touches errno, and that has changed several times due to the fact that that var became threadsafe.

Marco van de Voort wrote

OS X and FreeBSD have basically the same problem, however has some mitigating factors (they change mostly only with major versions, and have the ability to run older binaries using resp COMPAT and SDK system)

The SDK's on Mac OS X are only for compiling, not for running. The way it's solved on Mac OS X is by almost never breaking backwards compatibility at the library level (they've haven't done it yet for libc since the launch of OS X 8 years ago, although that's obviously not that long a time ago), and if they do they include both the old and the new library or framework.

Both libraries and frameworks have internal versioning information that enables automatically checking whether or not an application and a library are compatible. Standard library linking happens similar to on other Unix systems, with the filename being used to select the appropriate version. In case of frameworks, the framework bundle itself can contain multiple versions and the correct one is automatically selected when the application is launched.

Jonas

In our previous episode, Henry Vermaak said:

More or less. But FPC's rtl doesn't pretend to be an OS interface.

That's also why e.g. Windows suffers less from this. Library linking issues are more isolated and the API is very static. (stuff is added, but not changed)

Marco van de Voort wrote

The init code touches errno

No, it doesn't.

Jonas

2.4.0 was released in January 2001 and SuSE 7.1 in the same month with a 2.4.0 kernel or 2.2.18 ;)

Zitat von Henry Vermaak :

Not me, but Michael said that.
I would say, that using cthreads under Linux in an LCL app is ok. I didn't test yet a LCL app under OS X, *BSD or Sparc, so don't know if cthreads has a performance penalty there.

Threading on Windows works with Windows API functions.

Mattias

2009/8/27 Mattias Gärtner :

Not me, but Michael said that.

Of course, sorry for mis-quoting you.

Henry

A much longer than expected discussion, but informative none the less. Thanks to all for explaining.

And here one can see the difference. Static vs Dynamic executable.

$ ldd bench1.cthreads
linux-vdso.so.1 => (0x00007fff3f5ff000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f4b371b5000) libc.so.6 => /lib/libc.so.6 (0x00007f4b36e43000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4b373b9000)

$ ldd bench1.no-cthreads
	not a dynamic executable

$ ls -l
-rwxr-xr-x 1 graemeg graemeg 693840 2009-08-27 14:11 bench1.cthreads -rwxr-xr-x 1 graemeg graemeg 607112 2009-08-27 14:11 bench1.no-cthreads

Regards,
- Graeme -

En/na Marco van de Voort ha escrit:

It makes it very hard to longterm succesfully deploy a simple linux binary over several systems.

FWIW, yesterday I add to compile on a current system a 5 years old very simpe program (updated 2 years ago) with current lazarus/gtk2/fpc 2.2.4 to deploy on a 5 years old system (and that's nothing, sometimes I have to touch 15-20 years old systems) and it doesn't run (it claims it's missing some gtk2 function). Of course, I could reinstall those machines with a current distribution, but it'll take too much time for what is a simple modification to the program.
Luckily it works if compiled with gtk1.
This is to say that using cthreads by default (which, btw, my program uses) wouldn't make things that much worse.

Bye

[...] I would say, that using cthreads under Linux in an LCL app is ok. I didn't test yet a LCL app under OS X, *BSD or Sparc, so don't know if cthreads has a performance penalty there.

I did some tests on OS X and got some interesting results:

An LCL application without cthreads: 15 seconds
An LCL application with cthreads: 13 seconds
An LCL application with cmem: 13 seconds

This means LCL apps get faster with cthreads, while command line programs get slower.

Under Linux: no difference

procedure TMainForm.FormCreate(Sender: TObject);
var
  s1: String;
  s2: String;
  i: Integer;
  s: String;
begin
  s1:=IntToStr(Paramcount+12345);
  s2:=IntToStr(Paramcount+23456);
  for i:=1 to 500000000 do begin
    s:=s1;
    s:=s2;
  end;
end;

Mattias

Without saying what this command line application and this LCL application do exactly, it's kind of hard to understand this conclusion.

Jonas

Jonas Maebe wrote

Without saying what this command line application and this LCL application do exactly, it's kind of hard to understand this conclusion.

Oh, now I see that the procedure was put below :) That it's quicker with cmem is reasonably logical: FPC's heap manager is not very good at reallocating memory.

I didn't see any timings for the command line app in your post though. I guess the difference between the command line and LCL app is simply due to alignment differences, causing different cache behaviour.

Jonas

I already posted the code, so I guess you mean the libraries. How can I find out under OS X?

Mattias

What reallocating memory do you mean?

  s1:=IntToStr(Paramcount+12345);
  s2:=IntToStr(Paramcount+23456);
  for i:=1 to 500000000 do begin
    s:=s1;
    s:=s2;
  end;

I only change reference counters, don't I?

I didn't see any timings for the command line app in your post though.

That was in the very first post of this thread:

Under my Linux machine the above program takes about 7.5 seconds. Uncomment the cthreads unit: 7.5 seconds

Under OS X the above program takes on my mac book about 15 seconds. Uncomment the cthreads unit: 21 seconds

I guess the difference between the command line and LCL app is simply due to alignment differences, causing different cache behaviour.

Mattias

You're right.

> I didn't see any timings for the command line app in your post > though. That was in the very first post of this thread:

Maybe on another mailing list? Not here anyway.

On my MacBook it's 12 seconds with or without cthreads (12.1 with 2.5.1, 12.8 with 2.2.4).

Jonas

2009/8/27 Jonas Maebe :

> > That was in the very first post of this thread: Maybe on another mailing list? Not here anyway.

Nope, Mattias is right. He posted the results in the Lazarus mailing list, but when I moved the discussion from there to here, I quoted his results in my first posting.

Here they are again.
---------------------
Mattias test results are as follows:

Under his Linux machine the above program takes about 7.5 seconds. Uncomment the cthreads unit: 7.5 seconds

Under OS X the above program takes on his mac book about 15 seconds. Uncomment the cthreads unit: 21 seconds
---------------------

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

You're right. I clearly wasn't reading straight yesterday, I had read "in my first post of this thread".

Anyway, to check where the time difference comes from under Mac OS X, Shark can be used. Just compile everything with debug info and then run

shark -i ./testprogram

and afterwards,

open session_001.mshark

Make sure you have CHUD 4.6.2 installed (Shark is part of that package; it works both on 10.4 and 10.5), and that the binary is not on a network volume (for some reason, Shark doesn't find the symbol in that case).

You can download the latest version of CHUD from https://connect.apple.com (requires (free) registration if you don't have any form of Apple account yet).

Jonas