Parallel Logic Programming: A Sequel

[aarroyoc]

Under this name, a new survey contains different ideas that have been used to parallelize Prolog and other logic programming language. A very interesting read even if we're still a bit far from having multi threading.

Link: https://arxiv.org/abs/2111.11218

[pmoura]

Although multi-threading is only one of the possible solutions, it does allow high-level constructs for and-parallelism and competitive or-parallelism. An implementation of these constructs can be found in Logtalk (I can send you some papers on them). Those constructs were later copied under different names by SWI-Prolog and more recently by ECLiPSe. There's also a draft standardization proposal on Prolog threads. Unfortunately, only a few systems follow the proposal with SWI-Prolog being the only system that provides a reliable implementation. XSB abandoned support for threads recently and YAP support for threads have been too buggy to be usable. A few other systems made some implementations attempts (e.g. Ciao Prolog, Qu-Prolog) but don't really follow the proposal.

[aarroyoc]

The family of predicates: thread_create, thread_join, ... do not feel very Prolog at all, but it's true that allow building higher-level abstractions using them, so it's something a system could considerate adding (even if it does not promote its usage directly). Actually, I liked the Jolog ideas because they seem elegant and declarative while allowing the programmer to be explicit about parallelism. But I don't know if they have been battle-tested enough. Also, Logtalk threaded seems very powerful too

[triska]

Thank you for sharing this!

I really wonder how hard it would be to add support for multiple threads to Scryer Prolog. This would be extremely useful for example to implement HTTP and HTTPS servers. I think for a very rudimentary and still useful implementation, there would not even have to be much communication between different threads, only the ability to execute a single goal in its own thread. This would already be enough to spawn a "worker" thread that handles one specific client request. Rust is supposed to be especially well-suited for multithreaded applications.

There is also a fork crate: https://docs.rs/fork/latest/fork/ , but fork(2) is OS specific and also has other issues: https://internals.rust-lang.org/t/why-no-fork-in-std-process/13770 .

[aarroyoc]

That's something that I'm also looking forward to! Regarding fork, I think Scryer would be better by using green threads, which can be found in some Rust crates like Tokio (they call them Tasks). That means, you can't use fork (which are OS threads) and also fork will likely remove all safety measures of Rust in multithreaded environments.

[infogulch]

The Joy of Concurrent Logic Programming [1] is somewhat related. It proposes a language based on horn clauses with an execution model where all unification targets are queued up concurrently.

http://www.call-with-current-continuation.org/articles/the-joy-of-concurrent-logic-programming.txt