Example of threads and concurrency?

Example of threads and concurrency?

[Eric Abrahamsen]

I've read the chapter on threads in the manual, and sort of understand
it theoretically, but not really in practice.

Can someone look at the below and tell me if it makes sense? I'm trying
to make a simple system where there's a global variable, and I update
the variable with a time-consuming/network-bound computation. I want the
computation to happen in a thread so it doesn't block, and I want no
other code to touch the variable while the computation is happening.

The following works when I run it, but I have no idea if this is
actually how you do it.

#+begin_src emacs-lisp
(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.

Other questions:

1. Other code just has to know that it can't touch
   `important-data-variable' without holding `important-data-mutex',
   right?
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?
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 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.

Any light shed would be very welcome!

Eric

Re: Example of threads and concurrency?

[Eric Abrahamsen]

I floated this on emacs.help, but got no takers. I'm hoping someone here
might be able to help!

Thanks,
Eric

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I've read the chapter on threads in the manual, and sort of understand
> it theoretically, but not really in practice.
>
> Can someone look at the below and tell me if it makes sense? I'm trying
> to make a simple system where there's a global variable, and I update
> the variable with a time-consuming/network-bound computation. I want the
> computation to happen in a thread so it doesn't block, and I want no
> other code to touch the variable while the computation is happening.
>
> The following works when I run it, but I have no idea if this is
> actually how you do it.
>
> #+begin_src emacs-lisp
> (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.
>
> Other questions:
>
> 1. Other code just has to know that it can't touch
>    `important-data-variable' without holding `important-data-mutex',
>    right?
> 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?
> 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 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.
>
> Any light shed would be very welcome!
>
> Eric

Re: Example of threads and concurrency?

[Noam Postavsky]

On Sat, Feb 18, 2017 at 1:43 PM, Eric Abrahamsen
<eric@ericabrahamsen.net> wrote:
>> I update the variable with a time-consuming/network-bound
>> computation. I want the computation to happen in a thread so it
>> doesn't block,

You're out of luck, only one thread runs at a time.

>> 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.

Yes (although as I said above, there is no parallelism regardless).

>>
>> Other questions:
>>
>> 1. Other code just has to know that it can't touch
>>    `important-data-variable' without holding `important-data-mutex',
>>    right?

Yes.

>> 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?

The thread needs to call something that would yield, otherwise the
cancelling signal call will never have a chance to be sent.  The thread
doesn't need to handle the signal (assuming you're fine with just
quitting the thread).

>> 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?

To unblock the other thread that is waiting for it (2 paragraphs up):

    (with-mutex mutex
      (while (not global-variable)
        (condition-wait cond-var)))

>> 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.

They are used to synchronize between threads.  But if your thread is
just doing a single computation and then ends, make-thread and
thread-join can be an alternative to them.

Re: Example of threads and concurrency?

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sat, 18 Feb 2017 14:23:22 -0500
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> On Sat, Feb 18, 2017 at 1:43 PM, Eric Abrahamsen
> <eric@ericabrahamsen.net> wrote:
> >> I update the variable with a time-consuming/network-bound
> >> computation. I want the computation to happen in a thread so it
> >> doesn't block,
> 
> You're out of luck, only one thread runs at a time.

Only one thread runs at a time, but "network-bound" sounds like it
could yield from time to time, if it calls accept-process-output and
its ilk.

Re: Example of threads and concurrency?

[Noam Postavsky]

On Sat, Feb 18, 2017 at 2:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sat, 18 Feb 2017 14:23:22 -0500
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>> On Sat, Feb 18, 2017 at 1:43 PM, Eric Abrahamsen
>> <eric@ericabrahamsen.net> wrote:
>> >> I update the variable with a time-consuming/network-bound
>> >> computation. I want the computation to happen in a thread so it
>> >> doesn't block,
>>
>> You're out of luck, only one thread runs at a time.
>
> Only one thread runs at a time, but "network-bound" sounds like it
> could yield from time to time, if it calls accept-process-output and
> its ilk.

Oh, I missed the "network" part of that indeed.

Re: Example of threads and concurrency?

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> 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

Re: Example of threads and concurrency?

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> 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

Re: Example of threads and concurrency?

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Sat, 18 Feb 2017 12:40:54 -0800
> 
> 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?

It depends on what your network- or process-related code needs to do.
If it just reads whatever the process has to give and that's all, then
indeed, these two methods are roughly equivalent.  But if it has some
more complex processing, like waiting for the process, dealing with
errors, interacting with it, etc., then running that in a separate
thread can make your code much simpler and easier to write, while
letting the main thread (and thus the user) go about its business.

Re: Example of threads and concurrency?

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Sat, 18 Feb 2017 12:40:54 -0800
>> 
>> 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?
>
> It depends on what your network- or process-related code needs to do.
> If it just reads whatever the process has to give and that's all, then
> indeed, these two methods are roughly equivalent.  But if it has some
> more complex processing, like waiting for the process, dealing with
> errors, interacting with it, etc., then running that in a separate
> thread can make your code much simpler and easier to write, while
> letting the main thread (and thus the user) go about its business.

Okay, that makes sense.

Thanks again!
Eric