From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: About 'futures' Date: Tue, 8 Mar 2005 21:52:35 +0100 Message-ID: <66e540fe05030812526a7ccb6f@mail.gmail.com> References: Reply-To: djurfeldt@nada.kth.se NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1110316498 19489 80.91.229.2 (8 Mar 2005 21:14:58 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Mar 2005 21:14:58 +0000 (UTC) Cc: Mikael Djurfeldt , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 08 22:14:57 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D8lyo-0007D9-1j for guile-devel@m.gmane.org; Tue, 08 Mar 2005 22:11:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8mDK-00050T-Qn for guile-devel@m.gmane.org; Tue, 08 Mar 2005 16:26:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D8mCd-0004tb-DK for guile-devel@gnu.org; Tue, 08 Mar 2005 16:25:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D8mBq-0004ie-E8 for guile-devel@gnu.org; Tue, 08 Mar 2005 16:24:33 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D8mBg-0004d7-08 for guile-devel@gnu.org; Tue, 08 Mar 2005 16:24:20 -0500 Original-Received: from [64.233.170.194] (helo=rproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D8lgz-0003mw-Jw for guile-devel@gnu.org; Tue, 08 Mar 2005 15:52:39 -0500 Original-Received: by rproxy.gmail.com with SMTP id y7so1576344rne for ; Tue, 08 Mar 2005 12:52:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Nkg/X8eeLslK4PPKrY/VhoRtRoHP0os25jLKw+H/ZTX5cwk9d8Oj71nm9OUC+oWKPgSVbRFnfSD8wl53hTFCpK0UDUZZHa7zP7RE9bgVWJABXEphb+NMHbUhIOllZEcaxM5eFFnWYvnCMD0gRqtGIAKoHwrmR9KVum8Asal5mww= Original-Received: by 10.38.163.59 with SMTP id l59mr143873rne; Tue, 08 Mar 2005 12:52:35 -0800 (PST) Original-Received: by 10.38.104.39 with HTTP; Tue, 8 Mar 2005 12:52:35 -0800 (PST) Original-To: Marius Vollmer In-Reply-To: X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org X-MailScanner-To: guile-devel@m.gmane.org Xref: news.gmane.org gmane.lisp.guile.devel:4837 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:4837 On Tue, 08 Mar 2005 19:04:17 +0100, Marius Vollmer wrote: > what is the difference between > > (join-thread (begin-thread (foo))) > > and > > (future-ref (future (foo))) The first construct is guaranteed to start a new OS thread with its own, complete, dynamic context. The indended usage pattern is an application divided into a number of threads handling different tasks. The implementation is optimized for the completeness of the environment provided in the thread rather than, e.g., startup time. The second is a lightweight mechanism intended for fast, small-scale, parallelism, such as in the `letpar' or 'par-map' constructs which evaluate its component expressions in parallel. The implementation is optimized for quick start and delivery of the result rather than providing a complete context rooted in a new OS thread. The current implementation caches a number of "workers", so rather than spawning a new thread, `future' simply implies signalling a condition variable. (The current implementation is not complete since the dynamic context is not re-initialized for each evaluation in a worker thread. In order to complete the implementation one needs to define what "dynamic context" includes in this case. The aim is that it should be minimal.) > I am thinking about implementing futures as just > > (define-macro (future exp) `(begin-thread ,exp)) > (define future-ref join-thread) > > Would that make sense? I don't think so for obvious reasons. It would not make sense to spawn new pthreads for the kind of usage patterns for which futures are intended. In my opinion it's better to scrap futures entirely than to provide the suggested implementation above. But I would surely miss them. I have used these parallel language constructs to make computations go faster on an SMP machine. It makes beautiful sense when the subexpressions of a letpar are matrix computations with operations implemented on the C level. Note also that futures, by their nature, necessarily needs to be maintained together with the guile-core rather than being provided by a separate package. M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel