Hello fpc-pascal,

i have two questions :

1. how i can write multithreaded program in free pascal ( using linux unit and clone function ??? )

2. how i can move program to background - i want no output from program just its running in background ( to close command.com )

Hi,

if you are using linux try this:

uses crt,linux;
var t: text;
begin
assign(t,'/dev/tty12');
rewrite(t);
case fork of
  0: begin
     repeat
      delay(1000);
      write(t,'T1'#10#13);
      until false;
     end;
  else writeln('Tschö');
  end;
end.

The programm (the first process) exit's after calling. The cloned process outputs `T1' to tty12 until you kill it.

Stefan

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

http://www.sziegenbalg.de
http://www.simage.org

------------------------------------------------------------------ In a world without walls and fences, who needs Windows and Gates ?

You just call clone with the right arguments, and that is it.

2. how i can move program to background - i want no output from program just its running in background ( to close command.com )

Under Linux, just do

If fork0 then
  Exit;

Now the child is running in the background, and the parent has exited.

Michael.

Hi,

Subject: Re: [fpc-pascal]two questions plz help

Does that mean the RTL is already MT safe ?

Regards,
Thomas

No, it's not. So fork() is currently only useful if you do

a) no memory allocation (or if you use a thread-safe heap manager, such as the one in the cmem unit of the packages)
b) no IO
c) no errno error checking

I think the above are the only parts that are not thread safe...

Jonas

Subject: Re: [fpc-pascal]two questions plz help

> Does that mean the RTL is already MT safe ? No, it's not. So fork() is currently only useful if you do

I assumed because a developer answered to this question without mentioning this....

a) no memory allocation (or if you use a thread-safe heap manager, such as the one in the cmem unit of the packages)

This includes implicit memory allocations like ansistring handling, object creation, etc. I guess ?

b) no IO c) no errno error checking I think the above are the only parts that are not thread safe...

So if I used a unit like this for Win32 (I remember cmem being Linux only...) everything should be ok ? [Assuming that the Win32 system memory management is threadsafe]

---------------- start of unit
unit win32heap;
interface
{$mode delphi}
implementation
uses
 windows;
function win32getmem(size : longint) : pointer;
begin
 result := HeapAlloc(GetProcessHeap, 0, size);
end;
function win32freemem(var p : pointer) : longint;
begin
 result := HeapSize(GetProcessHeap, 0, p);
 HeapFree(GetProcessHeap, 0, p);
 p := nil;
end;
function win32freememsize(var p : pointer; size : longint) : longint;
begin
 result := win32freemem(p);
end;
function win32allocmem(size : longint) : pointer;
begin
 result := HeapAlloc(GetProcessHeap, HEAP_ZERO_MEMORY, size);
end;
function win32reallocmem(var p : pointer; size : longint) : pointer;
begin
 result := HeapReAlloc(GetProcessHeap, 0, p, size);
 if (result  p) then
  win32freemem(p);
end;
function win32memsize(p : pointer) : longint;
begin
 result := HeapSize(GetProcessHeap, 0, p);
end;
function win32memavail : longint;
begin
 result := 0;
end;
function win32maxavail : longint;
begin
 result := 0;
end;
function win32heapsize : longint;
begin
 result := 0;
end;
const
 Win32MemoryManager : TMemoryManager = (
  getmem : @win32Getmem;
  freemem : @win32Freemem;
  freememsize : @win32FreememSize;
  allocmem : @win32Allocmem;
  reAllocmem : @win32ReAllocmem;
  memsize : @win32MemSize;
  memAvail : @win32MemAvail;
  maxAvail : @win32MaxAvail;
  heapSize : @win32Heapsize;
 );
var
 defaultMemoryManager : TMemoryManager;
initialization
begin
 GetMemoryManager(defaultMemoryManager);
 SetMemoryManager(Win32MemoryManager);
end;
finalization
begin
 Writeln('exiting memory manager');
 SetMemoryManager(defaultMemoryManager);
end;
end.
--------- end of unit

Regards,
Thomas

I know. This has been said so many times, that you can forget it sometimes :) You're correct it should always be mentioned though.

Yes, they all use the currently installed heap manager.

Indeed. In fact, I've already heard of someone in the past who was succesful in creating an MT FPC program this way.

Jonas

Hi,

I know. This has been said so many times, that you can forget it sometimes :) You're correct it should always be mentioned though.

Sure....

Well, not me =) Regardless of that, is there still something to do to get FPC MT safe and basically operational ?

Regards,
Thomas

Well, not me =) Regardless of that, is there still something to do to get FPC MT safe and basically operational ?

Google this: "Concurrent Pascal"

I don't think FPC conforms to this, but I hope it does in the future.

Yes, the inoutres variable (and under Linux, the errno).

I think those are the main obstacles, though any global variable in the system unit can theoretically cause havoc (filemode for example).

Jonas

Hi,

Thomas Schatzl wrote

Well, not me =) Regardless of that, is there still something to do to get FPC MT safe and basically operational ?

I have some working MT code :-)). At the first time I had some trouble with i/o and mem. It can be solved with bolcking routines. The exception handling ist still a little bit sticky.

Example blocking code:

var lock_mem : boolean;
procedure getmem2(var pt:pointer; size:longint);
bein
while lock_mem do
 delay(1);
lock_mem:=true;
getmem(pt,size);
lock_mem:=false;
end;
procedure freemem2(var pt:pointer; size:longint);
bein
while lock_mem do
 delay(1);
lock_mem:=true;
freemem(pt,size);
lock_mem:=false;
end;

...
...

Regards,
Stefan

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

http://www.sziegenbalg.de
http://www.simage.org

------------------------------------------------------------------ In a world without walls and fences, who needs Windows and Gates ?

Subject: Re: [fpc-pascal]two questions plz help

So _if_ I built my own System unit from scratch (taking care of MT-safeness) everything would be ok ? (Sorry for repeating the question, just to be 100% sure....)

Regards,
Thomas

Under *unix :-)

Yes, I think so, maybe except FPU code.

Als je trouwens msn of icq hebt en dat handiger vindt: msn:
icq: 73059433

I'm sorry about this mail. It wasn't supposed to go here.

Inoures is thread safe, at least in the common code.

Yes. But this isn't necessary. At least the MT-safeness for Win32 in the 1.1 branch should have beta qualitiy, i.e. everything is implemented but it needs to be tested more deeply.

For unix/linux, at least rtl/inc/thread.inc needs some work (no critical sections yet).

(Sorry for repeating the question, just to be 100% sure....)

To enable the MT-safeness, the 1.1 rtl must be compiled with -dMT and I don't think that this will change in the future, i.e. the 1.1 compilers will come with a single threaded rtl, if you want to write MT programs you have to recompile the rtl.

This isn't two threads are in the "while lock_mem do delay(1);" loop, it's possible that when something else sets it to false, they both check it before the other one has set it to true. You need to do the testing and setting as an atomic operation.

Jonas

Jonas Maebe wrote

This isn't two threads are in the "while lock_mem do delay(1);" loop, it's possible that when something else sets it to false, they both check it before the other one has set it to true. You need to do the testing and setting as an atomic operation.

But the probability of that event is very low. It can been avoid by setting lock_mem to a thread specific ID (for example the PID):

var lock_mem  : longint;
procedure getmem2(var pt:pointer; size:longint);
var pid:longint;
begin
pid:=getpid; { maybe getpid needs more time than delay(1) }
repeat
 while lock_mem0 do
  delay(1);
 lock_mem:=pid;
 delay(1);
 until lock_mem=pid;
getmem(pt,size);
lock_mem:=0;
end;

I think this should avoid any pathological cases. :-)

Regards
Stefan

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

http://www.sziegenbalg.de
http://www.simage.org

------------------------------------------------------------------ In a world without walls and fences, who needs Windows and Gates ?

But it will cause sporadic and very hard to trace crashes. There's no use in making something "almost thread safe" :)

Jonas