[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: deferred cancellation of ipc
From: |
Niels Möller |
Subject: |
Re: deferred cancellation of ipc |
Date: |
14 Oct 2003 17:02:17 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Marcus Brinkmann <address@hidden> writes:
> Maybe you want to consider the following solution, which might be
> acceptable. Plus it is simple.
Stopping the thread while figuring out what it's doing seems like the
right thing to do. I think that's where the simplicity comes from.
For simplicity, I'd suggest that you skip the yield part, and just
have a loop sleeping one or a few timeslices at a time. The reason
that should work is that when we wake up either
1. The blocking thread hasn't reached the ipc call yet. Then we
have to sleep some more and try again.
2. The target thread is blocking in the ipc. Then we can cancel it
right away.
3. The target thread has finished the ipc. Then we can just return;
the target thread will notice thread_var_ipc_cancel == 1 the next
time it tries an ipc, which may in fact have happened already.
(I'm still tempted to suggest using some low-level trickery (like
examining the IP and modifying it if it's before the system call), in
case the stopped target thread is not currently in the ipc system
call. The main advantage would be that the cancellation function
would never block. But if works fine to go to sleep for a timeslice,
then the problem is solved and clever optimizations can be postponed
for later).
> Another thing: If two threads try to cancel another thread at the same time,
> I don't think it will work out too well. Mutual exclusion is required, for
> the stop/start of the thread alone, if not for any other reasons.
One should keep that mutex locked for the entire duration of the
cancellation function, including sleep time, right? If we accept that
cancelling a thread may block for a short while, then it doesn't
really matter if we block on l4_sleep or on mutex_lock, so I don't
think that is a big deal. It makes sense to have a per-thread mutex
that protects the thread control state.
Regards,
/Niels
- Re: deferred cancellation of ipc, (continued)
- Re: deferred cancellation of ipc, Marcus Brinkmann, 2003/10/14
- Re: deferred cancellation of ipc, Niels Möller, 2003/10/14
- RE: deferred cancellation of ipc, Volkmar Uhlig, 2003/10/14
- Re: deferred cancellation of ipc, Marcus Brinkmann, 2003/10/14
- Re: deferred cancellation of ipc, Marcus Brinkmann, 2003/10/14
- RE: deferred cancellation of ipc, Volkmar Uhlig, 2003/10/14
- Re: deferred cancellation of ipc, Marcus Brinkmann, 2003/10/14
- Re: deferred cancellation of ipc, Stefan Götz, 2003/10/15
- Re: deferred cancellation of ipc, Marcus Brinkmann, 2003/10/15
- Re: deferred cancellation of ipc, Marcus Brinkmann, 2003/10/14
- Re: deferred cancellation of ipc,
Niels Möller <=
- Re: deferred cancellation of ipc, Marcus Brinkmann, 2003/10/14
- Re: deferred cancellation of ipc, Marcus Brinkmann, 2003/10/14