Dear Glenn,
May be I didn't describe my issue clearly.
I mean this issue should be also exist in current 4.4 version, it wasn't
caused by our modification.
our met issue case was a timing issue as below:
1. intputThread enter into sleep status, because client didn't retrieve
data fast enough.
2. user stop the record action right at this time, so
ClientProxy::interrupt() will be called when try to stop, and it will set
CBLK_INTERRUPT and wake up mFutex.
void ClientProxy::interrupt()
{
audio_track_cblk_t* cblk = mCblk;
if (!(android_atomic_or(CBLK_INTERRUPT, &cblk->mFlags) &
CBLK_INTERRUPT)) {
(void) __futex_syscall3(&cblk->mFutex, mClientInServer ?
FUTEX_WAKE_PRIVATE : FUTEX_WAKE,
1);
}
}
3. AudioRecordThread continue to run and block at
ClientProxy::obtainBuffer() when try to wait mCblk->mFutex right just
after ClientProxy::interrupt() called.
status_t ClientProxy::obtainBuffer(Buffer* buffer, const struct timespec
*requested,
struct timespec *elapsed) {
...
__futex_syscall4(&cblk->mFutex, mClientInServer ?
FUTEX_WAIT_PRIVATE : FUTEX_WAIT, old & ~CBLK_FUTEX_WAKE, ts);
...
}
4. because stop action, when inputThread come back, it will just enter
standby() and will not call releaseBuffer to wake up AudioRecordThread
5. and RecordTrack destroy will call ClientProxy::interrupt() again, but
because CBLK_INTERRUPT was already set by its stop() function before, so
AudioRecordThread will still be blocked
So in bugreport we will see deadlock.
*You could check the code in AudioTrack Shared.cpp file.*
We want to remove the judgement in ClientProxy::interrupt().
let interrupt() didn't care about if it was interrupted before.
it just set the flag and wake up mFutex
But we has some concern, so we hope you could give me some suggestion.
Thanks
在 2014年10月14日星期二UTC+8下午1时35分01秒，eleven xiang写道：
> Dear All,
>
> firstly, I am sorry to trouble you for a Andriod Audio issue.
>
> in AudioTrackShared.cpp, for a recording case, we met below issue:
>
> recording case met overrun, so the inputThread will sleep a while, but
> AudioRecrodThread will continue to run and block at mCblk->mFutex.
> if right now, user stop the recording, and the inputThread has no chance
> to release mFutext, then to standby.
>
> And the client's interrupt was just called right before
> AudioRecordThread's obtainBbuffer try to wait mCblk->mFutex.
> @@ -209,13 +209,18 @@ status_t ClientProxy::obtainBuffer(Buffer* buffer,
> const struct timespec *reques
> }
> int32_t old = android_atomic_and(~CBLK_FUTEX_WAKE, &cblk->mFutex);
> if (!(old & CBLK_FUTEX_WAKE)) {
> int rc;
> if (measure && !beforeIsValid) {
> clock_gettime(CLOCK_MONOTONIC, &before);
> beforeIsValid = true;
> }
> int ret = __futex_syscall4(&cblk->mFutex,
> mClientInServer ? FUTEX_WAIT_PRIVATE : FUTEX_WAIT, old
> & ~CBLK_FUTEX_WAKE, ts);
>
> Then we will find that AudioRecrodThread will always be blocked, because
> RecordTrack's destory will also miss the wake mCblk->mFutex, for it was
> already Interrupted before.
>
> So I wonder why has below CBLC_INTERRUPT condition judgement before wake,
> Could we just remove it ?
>
> void ClientProxy::interrupt()
> {
> audio_track_cblk_t* cblk = mCblk;
> if (!(android_atomic_or(CBLK_INTERRUPT, &cblk->mFlags) &
> CBLK_INTERRUPT)) {
> (void) __futex_syscall3(&cblk->mFutex, mClientInServer ?
> FUTEX_WAKE_PRIVATE : FUTEX_WAKE,
> 1);
> }
> }
>
>
> Thanks
>
--
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-porting
---
You received this message because you are subscribed to the Google Groups
"android-porting" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
