From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Example of threads and concurrency? Date: Sat, 18 Feb 2017 21:27:04 +0200 Message-ID: <83tw7rpaev.fsf@gnu.org> References: <87tw81sudh.fsf@ericabrahamsen.net> <87h93r49wh.fsf@ericabrahamsen.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1487446019 31117 195.159.176.226 (18 Feb 2017 19:26:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Feb 2017 19:26:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 18 20:26:55 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 1cfAeg-0007GL-EF for ged-emacs-devel@m.gmane.org; Sat, 18 Feb 2017 20:26:50 +0100 Original-Received: from localhost ([::1]:59632 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfAel-0002QE-Vg for ged-emacs-devel@m.gmane.org; Sat, 18 Feb 2017 14:26:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfAeb-0002Q7-GY for emacs-devel@gnu.org; Sat, 18 Feb 2017 14:26:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cfAeY-0006qd-Bl for emacs-devel@gnu.org; Sat, 18 Feb 2017 14:26:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50844) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cfAeY-0006qZ-8C; Sat, 18 Feb 2017 14:26:42 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3419 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cfAeW-0005ff-7c; Sat, 18 Feb 2017 14:26:42 -0500 In-reply-to: <87h93r49wh.fsf@ericabrahamsen.net> (message from Eric Abrahamsen on Sat, 18 Feb 2017 10:43:42 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:212450 Archived-At: > 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 ;-). > 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. Btw, you will find a few working examples in thread-tests.el in the test suite. HTH