Hi,

When you create a new project in Lazarus, the default uses classe in the *.lpr file looks as follows:

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

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

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

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

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;

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

Regards,
- Graeme -

So, it won't be added by default. Don't add it, if you don't need it (or any or you required packages).

Vincent

But why not add it by default? Windows for example has multi-threading support compiled in, even if you use multi-threading or not in your application. This applied to Delphi and Kylix as far as I know.

Why not do the same for unix-type OSes? I don't understand the reasoning to not include it by default. Does it add such a lot to the executable file size? Does it add extra dependencies on libraries that might not exist in standard installs - though far as I know Posix is available in ANY unix-type OS like Linux, *BSD etc...

Regards,
- Graeme -

Zitat von Graeme Geldenhuys :

Multithreading means that all strings access need critical sections. So adding cthreads will deccelerate your application, even if you do not start any thread.

See also
http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Units_needed_for_a_multi-threaded_application

Mattias

Mattias G?rtner wrote

Multithreading means that all strings access need critical sections.

So is this always the case for Windows applications? Would that mean that applications that don't used multi-threading actually run faster under Linux, *BSD and OS X compared to Windows?

So adding cthreads will deccelerate your application, even if you do not start any thread.

Is this in theory, or has somebody actually done some speed tests to see by what factor the applications are slowed down? What would be a good test to see a speed difference?

See also http://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Units_needed_for_a_multi-threaded_application

Thanks for the link, but that wiki pages misses a vital piece of information - and the reason for this message thread. It should include the answer as to why Windows has multi-threading support enabled by default, but all other platforms do not. It just says that other non-Windows platforms are handled differently, but it doesn't say why.

Like I mentioned earlier, does that mean you cannot create a non multi-threaded application in Windows? Also does that mean non multi-threaded applications run faster on other platforms than on Windows, because Windows must use critical sections for all string access? If it's a requirement for Windows, why not for other platforms too.

Seeing the actually speed difference between enabled/disabled multi-threading support might answer this question and maybe be a valid reason. Is there a test suite for this speed comparison - so I can try it out myself?

Regards,
- Graeme -

I am writing on strange behaviour of g_strconcat() and g_strjoin() functions from Glib2 Unit.

They are declared as:

function g_strconcat(string1:Pgchar):Pgchar; cdecl; overload; varargs;
external gliblib;
function g_strjoin(separator:Pgchar):Pgchar; cdecl; overload; varargs;
external gliblib;

And are used as:

SomePChar :=  g_strconcat
(g_strstrip(pLStr[0]),'=',g_strstrip(pLStr[1]),Nil);

Where pLStr is a result of g_strsplit() function. It is declared as PPChar and is tested to be Not Nil. Also, pLStr[0] and pLStr[1] are tested to be Not Nil.

Compilation is OK. Execution provides "Runtime error 216".

It seams that there is a problem with parameters passing into g_strconcat(). It works goot with 2 parameters - like that: g_strconcat (g_strstrip(pLStr[0]),Nil) and provides Runtime error 216 in all other cases.

Regards, Alexey.

For example:

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.

Under OS X the above program takes on my mac book about 15 seconds. Uncomment the cthreads unit: 21 seconds
Uncomment the t:=TThread line: 53 seconds.
fpc 2.2.4

Under my Linux machine the: above program takes about 7.5 seconds. Uncomment the cthreads unit: 7.5 seconds
Uncomment the t:=TThread line: 20 seconds.
fpc 2.2.5 (afair 2.2.4 behaves similar)

In the above example the loop does not allocate memory so the cmem unit makes no difference. Normally it is recommended - at least under OS X.

Please find out and add the answer.

[...the same text in other words...]

Maybe this thread should be moved to the fpc list?

Mattias

Mattias Gaertner wrote

Under my Linux machine the: above program takes about 7.5 seconds. Uncomment the cthreads unit: 7.5 seconds Uncomment the t:=TThread line: 20 seconds. fpc 2.2.5 (afair 2.2.4 behaves similar)

// 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

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

I'll move this discussion over to the fpc-users mailing list as see what they say there.

Regards,
- Graeme -

ummm... how am i or anyone else to know that it should not be added by default??

i'm still learning Laz/FPC (on winX environment and trying to compile for OS/2 environment as well) ...

Maybe because the default template does not add by default?

Vincent