Quantcast
Channel: naudio Work Item Rss Feed
Viewing all articles
Browse latest Browse all 738

Commented Issue: Position set .. lock (this) { } [8072]

$
0
0
Just google lock this and there's plenty of explanation to go around. Short of it is that user of the class (eg. CLR) may lock the class too and cause a deadlock. The recommended approach are is private lock objects: object mylock = new object(); .... lock (mylock) { }

I ran into the WaveFileReader race condition again even with the Stream.Synchronized around the stream making it a SyncStream.

The way it happened is that while the PlayThread is doing it's thing and eventually accessing the file, in the GUI thread I had exposed the ability to use the stream Position. And it worked very nicely yesterday until I made some minor changes elsewhere and now it started breaking when reaching the end of the file.

So I tried the naive way of putting a lock around the read and the position but that only resulted in a deadlock when user was trying to set Position to be larger than filesize.


Summary: The way to go is probably do just like the framework. ie. no Stream.Synchronized that I suggested before and maybe even no locks in the Position code because they'll just fool the user into thinking he can call them from whatever thread when that's not the case. The necessary synchronization needs to happen on the client app because only he will ultimately know how the stuff is called.
Comments: has been resolved in the latest NAudio

Viewing all articles
Browse latest Browse all 738

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>