# Tabling inside Threads **URL:** \ **Category:** Help!\ **Created:** [December 15, 2019, 9:32pm UTC](https://swi-prolog.discourse.group/t/tabling-inside-threads/1627 "2019-12-15T21:32:45Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![aminemarref](https://avatars.discourse-cdn.com/v4/letter/a/7feea3/32.png) [@aminemarref](https://swi-prolog.discourse.group/u/aminemarref)\ **Post date:** [December 15, 2019, 9:32pm UTC](https://swi-prolog.discourse.group/t/tabling-inside-threads/1627/1 "2019-12-15T21:32:45Z")
Hello, Is it possible to have tabling inside threads forked by [first\_solution/3](https://www.swi-prolog.org/pldoc/doc_for?object=thread%3Afirst_solution/3)? My program’s knowledge base changes at runtime, and it is necessary for me to use [thread\_local/1](https://www.swi-prolog.org/pldoc/man?predicate=thread_local/1) instead of [dynamic/1](https://www.swi-prolog.org/pldoc/man?predicate=dynamic/1) to localize the changes that occur in the knowledge base to the thread that causes such changes. The predicates that are added/removed from the knowledge base during execution are all defined as [thread\_local/1](https://www.swi-prolog.org/pldoc/man?predicate=thread_local/1). How can I make this: `:- dynamic([some_predicate/1], [incremental(true)]).` work with [thread\_local/1](https://www.swi-prolog.org/pldoc/man?predicate=thread_local/1) so that each thread created by [first\_solution/3](https://www.swi-prolog.org/pldoc/doc_for?object=thread%3Afirst_solution/3) has its separate tabling structure(s)? Thanks. ---
**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 16, 2019, 7:45am UTC](https://swi-prolog.discourse.group/t/tabling-inside-threads/1627/2 "2019-12-16T07:45:33Z")
Tables can be _private_ (to a thread) or _shared_ (between threads). By default they are private. So yes, each thread participating in first\_solution/3 by default builds its own tables (an they are discarded as the thread terminates). That should be fine. In this case you also want a thread private (local) dynamic predicate that is incremental. There are a large number of ways to achieve that: ```prolog :- dynamic([p/1], [incremental(true), thread(local)]). :- dynamic (p/1) as (incremental, private). ``` Or in two steps: ```prolog :- dynamic([p/1], [incremental(true)]). :- thread_local p/1. ``` These alternatives come from the support for XSB syntax as well as something in line with the ISO tradition. Note that in XSB, `as` is a high-priority operator and parenthesis are not needed. In SWI `as` pre-existed as low-priority operator. Note that the domain of thread shared tabling is still rather unexplored. Where I could copy all tests from XSB for the other tabling properties, XSB’s shared tabling is barely existent and has no tests. I have created a few tests, but this is waiting for a good power user to explore all corners. So far that seems irrelevant to you. Welcome to the wonder world of tabling 🙂 ---
**Author:** ![aminemarref](https://avatars.discourse-cdn.com/v4/letter/a/7feea3/32.png) [@aminemarref](https://swi-prolog.discourse.group/u/aminemarref)\ **Post date:** [December 16, 2019, 7:47am UTC](https://swi-prolog.discourse.group/t/tabling-inside-threads/1627/3 "2019-12-16T07:47:34Z")
Thanks a lot! 🙂 ---
**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 16, 2019, 7:56am UTC](https://swi-prolog.discourse.group/t/tabling-inside-threads/1627/4 "2019-12-16T07:56:16Z")
P.s. Be aware that XSB doesn’t really combine threads and tables and has no test cases for it. This also implies there are no tests for thread local incremental predicates. I see little reasons why that wouldn’t work out of the box, but if you see something strange you should suspect SWI-Prolog as well as your understanding of tabling 🙂