Hi,
On 11/09/16 17:32, John Baldwin wrote:
It isn't predicted and avoided by turnstiles. In particular, the cv_signal has
no idea what lock is associated, so it can't try to do something "smart" and
move the thread from the sleepq to the lockq. You will pay the double context
switch.
Maybe t
On Wednesday, November 09, 2016 05:10:09 PM Hans Petter Selasky wrote:
> Hi,
>
> On 11/09/16 16:02, John Baldwin wrote:
> > On the other hand, doing the wakeup outside of the lock
> > avoids preempting during the wakeup only to immediately block on the lock
> > and
> > switch back to the thread
Hi,
On 11/09/16 16:02, John Baldwin wrote:
> On the other hand, doing the wakeup outside of the lock
avoids preempting during the wakeup only to immediately block on the lock and
switch back to the thread that did the wakeup.
This can be predicted and avoided by the turnstiles iff cv_signal()
On Monday, November 07, 2016 08:32:17 PM Hans Petter Selasky wrote:
> On 11/07/16 20:23, Oleksandr Tymoshenko wrote:
> >
> >> On Nov 7, 2016, at 10:27 AM, Hans Petter Selasky wrote:
> >>
> >> On 11/07/16 18:38, Oleksandr Tymoshenko wrote:
> >>> + bcm2835_audio_unlock(sc);
> >>> + c
> On Nov 7, 2016, at 11:51 AM, Hans Petter Selasky wrote:
>
> On 11/07/16 20:32, Hans Petter Selasky wrote:
>> On 11/07/16 20:23, Oleksandr Tymoshenko wrote:
>>>
On Nov 7, 2016, at 10:27 AM, Hans Petter Selasky
wrote:
On 11/07/16 18:38, Oleksandr Tymoshenko wrote:
> +
On 11/07/16 20:32, Hans Petter Selasky wrote:
On 11/07/16 20:23, Oleksandr Tymoshenko wrote:
On Nov 7, 2016, at 10:27 AM, Hans Petter Selasky
wrote:
On 11/07/16 18:38, Oleksandr Tymoshenko wrote:
+bcm2835_audio_unlock(sc);
+cv_signal(&sc->worker_cv);
Shouldn't cv_signal()
On 11/07/16 20:23, Oleksandr Tymoshenko wrote:
On Nov 7, 2016, at 10:27 AM, Hans Petter Selasky wrote:
On 11/07/16 18:38, Oleksandr Tymoshenko wrote:
+ bcm2835_audio_unlock(sc);
+ cv_signal(&sc->worker_cv);
Shouldn't cv_signal() be done locked, so that you don'
> On Nov 7, 2016, at 10:27 AM, Hans Petter Selasky wrote:
>
> On 11/07/16 18:38, Oleksandr Tymoshenko wrote:
>> +bcm2835_audio_unlock(sc);
>> +cv_signal(&sc->worker_cv);
>
>
> Shouldn't cv_signal() be done locked, so that you don't loose any
> transactions? CV's only w
On 11/07/16 18:38, Oleksandr Tymoshenko wrote:
+ bcm2835_audio_unlock(sc);
+ cv_signal(&sc->worker_cv);
Shouldn't cv_signal() be done locked, so that you don't loose any
transactions? CV's only wakeup the treads that are sleeping right there
and then.
--HPS
Author: gonzo
Date: Mon Nov 7 17:38:39 2016
New Revision: 308424
URL: https://svnweb.freebsd.org/changeset/base/308424
Log:
Fix locking in bcm2835_audio driver
- Move all VCHI activity to worker thread: channel methods are called with
non-sleepable lock held and VCHI uses sleepable l
10 matches
Mail list logo