2010
DOI: 10.1007/978-3-642-11503-5_22
|View full text |Cite
|
Sign up to set email alerts
|

A Simple and Efficient Implementation of Concurrent Local Tabling

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
1
1
1

Citation Types

0
8
0

Year Published

2010
2010
2018
2018

Publication Types

Select...
5
1

Relationship

1
5

Authors

Journals

citations
Cited by 7 publications
(8 citation statements)
references
References 12 publications
0
8
0
Order By: Relevance
“…Note that our goal with these experiments is not to prove that we can speedup the execution of tabled programs, despite this is an obvious goal of having a concurrent implementation. Other works have already showed the parallel capabilities of the use of multithreaded tabling [8,9]. Since parallelism is highly dependent on the available concurrency that programs have and on the way synchronization is done, we can easily select/construct programs where linear speedups can be achieved or, on the other hand, where no speedups exist.…”
Section: Resultsmentioning
confidence: 99%
“…Note that our goal with these experiments is not to prove that we can speedup the execution of tabled programs, despite this is an obvious goal of having a concurrent implementation. Other works have already showed the parallel capabilities of the use of multithreaded tabling [8,9]. Since parallelism is highly dependent on the available concurrency that programs have and on the way synchronization is done, we can easily select/construct programs where linear speedups can be achieved or, on the other hand, where no speedups exist.…”
Section: Resultsmentioning
confidence: 99%
“…Variant sub-computations by other threads are resolved by consuming the answers stored by the generator thread. When a set of sub-computations being computed by different threads is mutually dependent, then a usurpation operation [12] synchronizes threads and a single thread assumes the computation of all sub-computations, turning the remaining threads into consumer threads. This maintains the correctness of the table space but has a major disadvantage: it restricts the potential of concurrency to non-mutually dependent sub-computations.…”
Section: Xsb's Approach To Multithreaded Tablingmentioning
confidence: 99%
“…The idea behind the Concurrent Local evaluation is that when a thread T encounters a (shared) tabled subgoal S that has not been encountered by any thread, T evaluates S. Other threads are allowed to use the table for S only after T has completed S. Concurrency control for tables mainly arises when more than one thread evaluates different tabled subgoals in the same SCC simultaneously. In this case a deadlock would occur, which the engine detects and resolves so that a single thread assumes computation of all tabled subgoals in the SCC (Marques and Swift 2008;Marques et al 2010). For example, in Figure 2 such a situation would occur if a thread T 1 called reach(1,Y) and another called reach(3,Y) before it was called by T 1 .…”
Section: Multi-threadingmentioning
confidence: 99%