[fpc-pascal]Crashes with multithreading

[md]

Nico:

I would like to suggest that the FPC team is doing an excellent job! Not
just a good job.  Since they are volunteers,
they are entitled to play around as much as they deem fit.  But I think
that they also want stability as well, so they won't stray to far in
their "playing around"

Michael Van Canneyt and Florian and others are as close as saints as you
can get.  FPC has been a pleasure to use, even
with some "stability" issues.  And it is more multi
OS/platform/processor every day.  Something Delphi for Linux will never
hope to be.

For your critical section/mutex problem, use semaphores.  They are multi
process safe as well as intraprocess safe, you
just have to use them with some coding discipline.  They are 5 times
more reliable than Windows NT critical sections because you can safely
use IPC_NOWAIT whereas TryCriticalSection under NT is a JOKE!

You can even get the PID of the semaphore to know which process changed
the value to zero or one, thus creating a way to test to see if a given
process has already locked it and thus prevent deadlock.

The trick to remember is that when you create the semaphore, it is
opened with value of zero, which is LOCKED.  Then you must add one to
its value to unlock it.  Do not get caught up in any other values other
than one for unlocked or zero for locked.  Use IPC_NOWAIT because that
means your code will not get stuck on a semaphore.

Also, a semaphore does not get destroyed because you application
terminates.  A semaphore lives forever until you specifically kill it. 
You can re-run you application many times and the same kernel memory
would be used for each semaphore if you use the same ftok() value to
generate it.  In fact, I would recommend not killing it, but leave it
defined between executions of your application.  The application won't
care that it is already created.

You can pass the semaphore value between threads AND processes, so it is
portable.  Any process or thread can unlock the semaphore (root
privilege maybe reqd), but I would recommend that only the process that
created it should unlock it if you should have some stray code lock the
thing, then throw an exception, die, and not unlock it for others to
use.

On any command line shell, type: man semget or man semop. This should
provide you with information on the semaphores.  You can use the IPC
unit to get access to the semaphore functions.

Multi threaded applications are supposedly hard to debug with gdb, so be
wary of that pitfall when you decide code architecture.

Sincerely,

Mark Diener
Atlanta, GA, USA



Nico Erfurth wrote:
> 
> Hi,
> 
> >>> Shortly said: Yes. The only solution for this is to use separate
> >>> streams in each thread, then it'll work fine.
> >>
> >> The problem is, nothing in FPC is threadsafe, even the TThread-Class
> >> itself (InitThreads/DoneThreads).
> >> The FPC-Team really needs to make the RTL and all other classes
> >> threadsafe. Its nearly impossible to trace errors in threaded applications.
> >
> >
> > That is not entirely true; the Belgian national phone company collects data
> > from their telephone stations using a multi-threaded Win32 application
> > written in FPC.
> >
> > After changing the standard memory manager with the memory manager of
> > Windows itself the application runs very stable. It is just a matter
> > of programming it right; there are some small parts that require some
> > attention (such as file IO) but most of the RTL is thread-safe.
> >
> > The biggest problems are IOResult and the heap manager.
> > Avoiding these two makes FPC apps pretty thread-safe.
> >
> > Which of course doesn't mean we won't work on thread-safety :-)
> >
> > Michael.
> >
> 
> Sorry, i forget to say that i was talking about the Linux-version.
> And i think, to provide a class named TThreadList and dont make it
> thread-safe is not very common ;)
> 
> The next problem in linux-version is the lack of
> Mutexes/Critical-Sections, which makes real threaded applications nearly
> impossible with FPC/Linux.
> 
> regards Nico Erfurth
> 
> P.S. Alltogether the FPC-Team is doing a good job, but maybe they
> shouldnt "Play around" so much and do some more work to make everything
> stable (on all plattforms).
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal