From jan@swi.swi.psy.uva.nl Mon Dec 10 10:20:12 2001
Received: from gollem.swi.psy.uva.nl (root@gollem.swi.psy.uva.nl [145.18.152.30])
	by swi.psy.uva.nl (8.11.6/8.11.2) with ESMTP id fBA9KCA26548;
	Mon, 10 Dec 2001 10:20:12 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]])
	by gollem.swi.psy.uva.nl (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) id fBA9KCH24256;
	Mon, 10 Dec 2001 10:20:12 +0100
From: Jan Wielemaker <jan@swi.psy.uva.nl>
Organization: SWI, University of Amsterdam
To: Mihir Malviya <mihir@noida.hcltech.com>, prolog@swi.swi.psy.uva.nl
Subject: Re: [SWIPL] Multithreading problem
Date: Mon, 10 Dec 2001 10:10:09 +0100
X-Mailer: KMail [version 1.0.29.2]
Content-Type: text/plain
References: <E04CF3F88ACBD5119EFE00508BBB2121B1C2D1@exch-01.noida.hcltech.com>
In-Reply-To: <E04CF3F88ACBD5119EFE00508BBB2121B1C2D1@exch-01.noida.hcltech.com>
MIME-Version: 1.0
Message-Id: <01121010201100.23773@gollem>
Content-Transfer-Encoding: 8bit

On Mon, 10 Dec 2001, Mihir Malviya wrote:
>
>Hi,
>  I need to embedded SWI-prolog into a c++ application which is
>multithreaded.My query is , do I have to build prolog using the
>multi-threaded option?
>or  can the single threaded version also be embedded into the application?

This is possible, but then you should ensure the engine is called
respecting all synchronisation requirements of the single-threaded
version.  In practice this means you need a mutex that ensures only
one thread is busy preparing, calling and handling query-results.

>My second query is the sequence of calls for running in an multithreaded
>environment...
>ie do I need to call PL_initialize(), and if yes, should it be called before
>or after PL_thread_create() ?

If you choose for using the multi-threaded version you still have to
call PL_initialise() before anything else.  Next, a C-thread can decide
to attach an `engine' (set of Prolog stacks that allows for answering
queries) to the thread.  (The thread calling PL_initialise() has an
engine attached right away).  See PL_thread_attach_engine().

What is better depends on your application.  In general I'd go for the
single-threaded version whenever it is feasible to reach a good design
on this basis.  It is just simpler and more robust.  Even if concurrency
is a must (for example because you have multi-processor hardware and
you want to use it) I'd always first check whether using fork() is not
a better option.  In many cases this is the case as it provides good
isolation between the workers which allows the interacting processes
to act appropriately on failing workers.

	Cheers --- Jan

