From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Example of threads and concurrency? Date: Sat, 18 Feb 2017 12:40:54 -0800 Message-ID: <87o9xz1bc9.fsf@ericabrahamsen.net> References: <87tw81sudh.fsf@ericabrahamsen.net> <87h93r49wh.fsf@ericabrahamsen.net> <83tw7rpaev.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487450512 11959 195.159.176.226 (18 Feb 2017 20:41:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Feb 2017 20:41:52 +0000 (UTC) User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 18 21:41:47 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cfBpA-0002Qw-33 for ged-emacs-devel@m.gmane.org; Sat, 18 Feb 2017 21:41:44 +0100 Original-Received: from localhost ([::1]:59798 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfBpF-0001Mz-Qu for ged-emacs-devel@m.gmane.org; Sat, 18 Feb 2017 15:41:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfBoa-0001Mj-GU for emacs-devel@gnu.org; Sat, 18 Feb 2017 15:41:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cfBoX-0003HY-DM for emacs-devel@gnu.org; Sat, 18 Feb 2017 15:41:08 -0500 Original-Received: from [195.159.176.226] (port=40477 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cfBoX-0003HE-5J for emacs-devel@gnu.org; Sat, 18 Feb 2017 15:41:05 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cfBoO-0006oG-Od for emacs-devel@gnu.org; Sat, 18 Feb 2017 21:40:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 119 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:CODQrfhgIVg3i0+GXHK58vz5TzE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:212453 Archived-At: Eli Zaretskii writes: >> From: Eric Abrahamsen >> Date: Sat, 18 Feb 2017 10:43:42 -0800 >> >> I floated this on emacs.help, but got no takers. > > If you mean gnu.emacs.help, then I never saw this there. > >> I'm hoping someone here might be able to help! > > These issues are quite tricky, so please take what's below with a > grain of salt. > >> The following works when I run it, but I have no idea if this is >> actually how you do it. > > There's more than one way to skin this cat. > >> (defvar important-data-variable nil >> "Important variable holding important data. >> >> Our goal is to update this data.") >> >> (defvar important-data-mutex (make-mutex)) >> >> (defun update-important-data () >> (with-mutex important-data-mutex >> (let ((result '(1 2 3))) ; Slow function here. >> (setq important-data-variable result)))) >> >> (defun update-data-in-thread () >> (let* ((thread (make-thread #'update-important-data)) >> (timer (run-at-time >> 10 nil >> `(lambda () >> (when (thread-alive-p ,thread) >> (thread-signal ,thread 'give-it-up)))))) >> (thread-join thread))) >> #+end_src >> >> Is everything in the right place? It just occurs to me that If I put >> `thread-join' at the bottom of `update-data-in-thread' then it will >> effectively be synchronous after all! So I put that somewhere else, or I >> don't call it at all. > > IMO, either you want to wait for the other thread, or you don't. If > you do, then the timer makes little sense; you might as well have > simply called sleep-for. If you don't want to wait, then thread-join > is unnecessary, but you should be aware that if the main thread goes > on about its business, the other thread will not run until the main > one becomes idle in some way or calls one of the synchronization > functions (like thread-join ;-). Okay, thanks to both you and Noam for this. I guess I knew that only one thread can run at a time, but hadn't really *got* it. In my dumb example I had indeed expected to use accept-process-output. But there's not a whole lot of advantage of using threads plus accept-process-output over just using start|make-process with sentinels and callbacks, right? >> 1. Other code just has to know that it can't touch >> `important-data-variable' without holding `important-data-mutex', >> right? > > Not really, because only one thread can run at any given time, so it's > impossible to have more than one thread access this variable at the > same time. You have to use a mutex only when threads which will read > the variable must wait until the variable is updated. > >> 2. I want the timer to signal the thread to give up after ten seconds -- >> do I need to put anything in `update-important-data' that handles >> that signal? > > No, not if what you want is for the signaled tread to exit. > >> 3. What do condition vars actually do? The manual has an example that >> looks just like what I'm doing above: >> >> (with-mutex mutex >> (setq global-variable (some-computation)) >> (condition-notify cond-var)) >> >> What is cond-var doing here? > > It's a condition variable on which some other thread can wait. > >> It seems like both mutexes and cond-vars are there so other code knows >> when to keep its hands off `important-data-variable', but I don't >> understand how they're actually used. > > A mutex is useless, unless you know that the other thread already took > it. Otherwise, an attempt to take the mutex will immediately succeed, > and the other thread won't be able to do its job, because it wouldn't > be able to take the mutex (and actually won't even get run, because > the call to mutex-lock won't block). IOW, with mutexes, you have to > ensure a certain order of threads taking it. > > By contrast, with conditional variables, the thread waiting for some > job to be done by another thread can start waiting before that other > thread runs, or after that, so the order matters less. > > Put it another way, cond-vars are for waiting on events which could > occur either before or after you start waiting; mutexes can only be > waited on for something that occurs after you start waiting. Oof, I'm going to have to read the above a few times. > Btw, you will find a few working examples in thread-tests.el in the > test suite. Brilliant! It's great to have some examples to look at. I'll be back later with more questions, I'm sure, but all this will get me pretty far along. Thanks! Eric