Re: Some questions about concurrency (mostly)

[Fredrik Appelberg]

felix.winkelmann@bevuta.com writes:

Hi, and thanks for the reply :)

>> 1. Are there any problems with creating a condition (as in exception,
>>    not srfi-18 condition variable) in one thread and raising it in one
>>    or more other threads?
>
> No problem here, I'd say, data can be freely exchanged between threads,
> since they share a global address space. A condition object is just a
> data structure.

Cool. I was thinking there might be some thread-dependent stack
information in there. 

>> 2. In my application I'm running a thread that reads from a TCP port and
>>    dispatches frames back to the main thread using a mailbox (from the
>>    mailbox egg). I'm also running a separate thread that sends a
>>    heartbeat frame back over the TCP connecion every 30s. This works
>>    fine, but I've noticed that after a while (this seems to happen
>>    consistently after the first heartbeat has been sent) I cannot press
>>    Ctrl-C in the terminal to stop the application. However, as soon as
>>    the dispatcher thread reads an incoming frame, the process is
>>    interrupted. I assume this has something to do with blocking threads?
>>    Is there something I can do about it?
>
> Is this in a compiled application or inside csi? If the former, do you install
> a handler for SIGINT?

This is when running under csi. I hadn't thought about testing the
compiled version, but when I do it works as expected (Ctr-C interrupts
the application).

I haven't tried installing a signal handler since it kinda works for a
short time and I was convinced I was doing something wrong with the
threads. After testing some more I'm starting to think this maybe has
something to do with csi buffering input. I'll have to do some
experimentation here.

>> 3. I'm new to dynamic-wind. If I wanted to create a general form for
>>    executing a thunk protected by a mutex, would this be a good idea?
>> 
>>      (define (with-lock mutex thunk)
>>        (dynamic-wind
>>           (lambda () (mutex-lock! mutex))
>>               thunk
>>               (lambda () (mutex-unlock! mutex)))))
>> 
>>    I read somewhere that the before- and after-guards might execute
>>    multiple times, but then again I'm not really sure under what
>>    circumstances so I might be way off.
>
> Whenever the continuation is re-invoked, the before/after thunks
> will be called on entering the dynamic context in which the 2nd 
> thunk above will be executed, and the before/after thunks will
> always be called in pairs, so your approach looks fine to me.
>
> For example, load this into csi:
>
> (define k0 #f)
> (define k1 #f)
>
> (define (foo)
>   (call/cc
>     (lambda (k)
>       (dynamic-wind
>         (cut print 'before)
>         (lambda ()
>           (set! k0 k)
>           (call/cc
>             (lambda (k2)
>               (set! k1 k2)
>               #f))
>           (k 99))
>         (cut print 'after)))))
>
> #;1> (foo)
> before
> after
> 99
> #;2> (k0 100)
> 100
> #;3> (k1 101)
> before
> after
> 99
>
> dynamic-wind is powerful, but can be very confusing, expecially
> if you mix in threads and exceptions. Better try to keep the
> control-flow of your code simple.
>

That part of my code contains a large number of pretty similar
functions, all which require a mutex lock to run. In order to make the
code cleaner I could either try dynamic-wind or create a macro.

I'm not doing any call/cc or non-local exit shenanigans, but the code
uses srfi-18 threads and does I/O over TCP. As I understand it, srfi-18
is implemented using continuations. Will that cause problems with my
with-lock function? I'm thinking that a thread that has aquired the lock
in the before-thunk and running the main thunk might hang waiting for
I/O; will that cause it to exit the dynamic environment, run the
after-thunk and release the lock?

>> 
>> 4. The srfi-18 thread scheduler seems to behave slightly differently
>>    when running compiled code and in csi. Is that correct?
>
> This depends on what you mean with "slightly". Interruption
> of running threads (because the time-slice is used up) will happen
> at different points in interpreted vs. compiled code - compiled code
> is more compact and has of course completely different timing
> behaviour. Can you elaborate on what you mean with "differently"?

I noticed that while running in csi one thread would execute three read
operations on a TCP connection in a row without being interrupted, but
the same code running under csc would mix in a write operation from
another thread. Which was probably a good thing, since that made me
realize I had a race condition :) It's probably down to the different
timing behaviour you mention.

Thanks again for the input! (and for Chicken Scheme!)

Cheers,
-- Fredrik