Re: Example of threads and concurrency?

[Eric Abrahamsen]

Eli Zaretskii <address@hidden> writes:

>> From: Eric Abrahamsen <address@hidden>
>> 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