Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2012-06

Parallel procedures

8 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mattias Gaertner

Hi,

FPC does not yet have parallel loops/procedures, but there is a unit that helps to create parallel procedures/methods (mtprocs).

http://wiki.freepascal.org/Parallel_procedures

I use this unit since 4 years in several of my projects, which run on linux, os x and windows. Not much was done on the unit in the last years, because it simply works.

mtprocs implements a thread pool, although it is not a general purpose one.

It uses one extra unit mtpcpu, which has a function to guess the number of cores.

I think both features would be nice to have in fpc by default, so maybe they should be added.

What do you think?

Mattias

Reply by email

Alexander Klenin
to Mattias Gaertner
Mattias Gaertner wrote
What do you think?

Why not -- although IMO it would be much better to have some lagnuage-level support
for things like single-owner semantics.

Independenty, it seems that the unit should be updated to support "is nested" modifier.

Alexander S. Klenin

Reply by email

Michael Schnell
to Alexander Klenin
Alexander Klenin wrote 9 lines
On Fri, Jun 15, 2012 at 9:39 AM, Mattias Gaertner wrote: > What do you think? > Why not -- although IMO it would be much better to have some lagnuage-level support for things like single-owner semantics.

Yep. I think parallel loops and futures like defined in Prism might be quite user-friendly.

Regarding an implementation fast enough to take real advantage of multiprocessor boxes, a native support for Futex (instead of going via the pthread library) might be helpful (no idea about the Windows and Mac equivalents).

Maybe the (speed-wise) somewhat sub-optimal (regarding most C compilers) implementation of (on some processors/OSes) threadvars might be improved.

-Michael

Reply by email

Sven Barth
to Michael Schnell
Michael Schnell wrote
Regarding an implementation fast enough to take real advantage of multiprocessor boxes, a native support for Futex (instead of going via the pthread library) might be helpful (no idea about the Windows and Mac equivalents).

The Linux unit already contains Futex functions that directly call the kernel (since around two years already).

Regards,
Sven

Reply by email

Unknown author
to Mattias Gaertner: FPC does not yet have parallel loops/procedures, but there is a unit that helps to create…
Mattias Gaertner wrote 21 lines
Hi, FPC does not yet have parallel loops/procedures, but there is a unit that helps to create parallel procedures/methods (mtprocs). http://wiki.freepascal.org/Parallel_procedures I use this unit since 4 years in several of my projects, which run on linux, os x and windows. Not much was done on the unit in the last years, because it simply works. mtprocs implements a thread pool, although it is not a general purpose one. It uses one extra unit mtpcpu, which has a function to guess the number of cores. I think both features would be nice to have in fpc by default, so maybe they should be added. What do you think?

Pending language support for parallellism, I think this is a good idea.

Michael.

Reply by email

Michael Schnell
to Sven Barth: The Linux unit already contains Futex functions that directly call the kernel (since…
Sven Barth wrote
The Linux unit already contains Futex functions that directly call the kernel (since around two years already).

I did not check the RTL source code. But it needs to be noted that the term "call Futex" is rather unclear.

There is a Kernel function "FUTEX" that helps to implement a Futex ("Fast Userspace MUTEX") based Semaphore.

But the idea with FUTEX is in by far most cases _not_ to all this kernel function, but to handle the Semaphore completely in Userspace, if not taken. The userspace code related to Futex is very critical ASM stuff and not easy to do. (See "FUTEXES are tricky" by Ulrich Drepper http://people.redhat.com/drepper/futex.pdf ) So providing a wrapper for the Futex Kernel call does not help at all).

For C, the userspace code is done in the pthread library. (In fact, pthread_mutex_..() uses the Futex mechanism if the architecture in fact does provide the appropriate CPU instructions and the Kernel provides the related kernel call - which of course is for X86 / X86/64 and modern Linux - , otherwise it just uses the appropriate Kernel Space MUTEX call.).

What I meant is that the RTL should implement e.g. TCriticalSection (and whatever might be used to provide multi-thread libraries and/or language extensions) using the FUTEX mechanism without needing the pthread libc library. (Maybe this already is done.)

-Michael

Reply by email

Mattias Gaertner
to Alexander Klenin: On Fri, Jun 15, 2012 at 9:39 AM, Mattias Gaertner Why not -- although IMO it would be…
Show quoted text 11 lines
On Fri, Jun 15, 2012 at 9:39 AM, Mattias Gaertner wrote: > What do you think? > Why not -- although IMO it would be much better to have some lagnuage-level support for things like single-owner semantics. Independenty, it seems that the unit should be updated to support "is nested" modifier.

Since which fpc version exists "is nested"?

Mattias

Reply by email