# Efficiently use concurrency predicates to find n solutions **URL:** \ **Category:** General\ **Created:** [December 30, 2024, 9:03pm UTC](https://swi-prolog.discourse.group/t/efficiently-use-concurrency-predicates-to-find-n-solutions/8703 "2024-12-30T21:03:14Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![z5h](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/z5h/32/5445_2.png) [@z5h](https://swi-prolog.discourse.group/u/z5h)\ **Post date:** [December 30, 2024, 9:03pm UTC](https://swi-prolog.discourse.group/t/efficiently-use-concurrency-predicates-to-find-n-solutions/8703/1 "2024-12-30T21:03:14Z")
We have `first_solution/3` to efficiently perform concurrent searches for a solution. We have `findnsols/4` to find (up to) the first n solutions. It stands to reason that someone might want to perform concurrent searches for (up to) n solutions. I’m currently that someone. It seems there’s plenty to work with in SWI-Prolog’s multithreading library for a DIY implementation. I just want to avoid reinventing the wheel if there’s something else I should be looking into. Is there? An important note is that the separate goals (strategies) I’d use to generate solutions have a very low likelihood of creating redundant solutions between themselves, (and I don’t care if they do). ---
**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\ **Post date:** [December 31, 2024, 8:52am UTC](https://swi-prolog.discourse.group/t/efficiently-use-concurrency-predicates-to-find-n-solutions/8703/2 "2024-12-31T08:52:20Z")
There is nothing out of the box. It is basically a variant on first\_solution/3 though, where you merely have to wait for N rather than 1 (and again decide what to do with failure or errors). I’m happy to handle a PR that adds this. It seems a reasonable thing to have.