Re: futures and parallel forms in Guile and Bigloo

Hello Joseph.

You wrote, 2020-09-20 18:43:
> Hello, Sven,
>
> I got a chance to look at the jvm issues this weekend and have made an update that results in a mostly working implementation; there still remains a race condition when shutting down an executor that results in futures being in a finished state instead of the expected terminated state at times. I will continue to
> look into this but don't see it as super critical. As before, changes were required to the bigloo pthread library, I refactored the bglpmutex class to use ReentrantLock. This gives the jvm version of the pthread library proper recursive mutexes. The changes can be found at
> https://github.com/donaldsonjw/bigloo-1/tree/pthread_modifications.
>
> If you get a chance to try it out, let me know what you think.

I am only using the C backend; so I cannot talk about your improvements for the Java
backend.
For the C backend, I have tried some smaller examples.
Your library seems to be solid and correct!
The performance is a little bit disappointing so far, but maybe this
will change when I look at some more advanced/real-life code segments.

How does your library choose the number of available threads (if the code
contains only calls of future and future-get from bigloo-concurrent)?
Number of physical cores, numer of virtual cores, ...?

Greetings
Sven

> Best Regards,
> Joseph Donaldson
>
> .
>
> On Sunday, September 6, 2020, 12:25:14 PM PDT, Joseph Donaldson <[email protected]> wrote:
>
> Hello, Sven,
>
> I took a look at porting scheme-concurrent to Bigloo. The results can be found at https://github.com/donaldsonjw/bigloo-concurrent. The native back-end passes all the tests but there are still some issues with the jvm back-end; I will continue to work on it. While doing the port, I made a few changes to Bigloo.
> These are linked from the bigloo-concurrent README. I have made a pull request to have the changes included in the Bigloo mainline.
>
> Let me know what you think.
>
> Best Regards,
> Joseph Donaldson
>
>  On Thu, Aug 20, 2020 at 8:34 AM, Sven Hartrumpf
>  <[email protected]> wrote:
>  Hello Joseph.
>
>  Thanks for your message and the link to hop code.
>  I must admit that this looks a little bit scary to me.
>  Maybe it is easier to port https://github.com/ktakashi/scheme-concurrent
>  (which already runs on several Schemes) to Bigloo?
>  It was presented at the Scheme Workshop 2016:
>  http://schemeworkshop.org/2016/ (it's the second talk)
>
>  Greetings
>  Sven
>
>  Joseph wrote, 2020-08-06 17:30:
>  > Hello, Sven,
>  >
>  > Given Bigloo's support for threads (pthreads or java threads), efficiently implementing Guile's futures and parallel forms is definitely possible. As mentioned in the Guile documentation, the most obvious implementation would be to introduce a threadpool abstraction and
>  > build the futures and parallel-forms on top of that. Manuel created a similar abstraction for his hop executors. See https://github.com/manuel-serrano/hop/blob/master/src/queue_scheduler.scm. Taking a look at Java's ThreadPoolExecutor abstraction may also be helpful.
>  >
>  > I think this would be an interesting project and would be willing to contribute to it.
>  >
>  > Best Regards,
>  > Joseph Donaldson.
>  >
>  > On Wednesday, August 5, 2020, 3:04:46 AM PDT, Sven Hartrumpf <[email protected]> wrote:
>  >
>  > Dear Bigloo users.
>  >
>  > I read about futures in Guile (see https://www.gnu.org/software/guile/manual/html_node/Futures.html)
>  > and the parallel forms built on-top, e.g. parallel, par-map and par-for-each
>  > (see https://www.gnu.org/software/guile/manual/html_node/Parallel-Forms.html).
>  >
>  > They look very promising,
>  > especially because 8, 16 or more CPU cores are available on more and more
>  > standard CPUs.
>  >
>  > Can these constructs be efficiently implemented in Bigloo, too?
>  >
>  > Greetings
>  > Sven