Thanks for the response. <br><br>I'm fairly new with using threads as the code that ran the entire game before never needed to create a separate thread. The only thing I've tried with a mutex was locking it during the beginning of the ReadStrmData call (which is basically all the separate music thread calls) and then unlocking it at the end of that call. The reason I tried this is I noticed a while ago much of the crashes would occur during the main thread, after let's say it read in somewhere around half the 4096 bytes that ReadStrmData normally reads in. In other reads it would not fully complete that function, go back to the main thread and would basically randomly crash.<br>
<br>"This is not the case for libvorbis and libogg. You<br>
need to explicitly synchronize use of the API over each object. I don't see<br>
any locking in the code you posted."<br><br>Since at the moment I have the code so the OggVorbis_File is basically a global variable there's only one object called ovf in the code. I probably should have sent the callback functions as well. That object is passed in through ov_open_callbacks. I'm not exactly sure where mutexes would need to be used. As mentioned attempting to lock the entire ReadStrmData function until it's complete didn't seem to change anything in regards to the crash. Is it possible that multiple mutexes need to be used in side some of the call back functions. <br>
<br>Here's some of the code I left out before:<br><br>const ov_callbacks my_callbacks = {<br> OggRead,<br> OggSeek,<br> OggClose,<br> OggTell<br> };<br><br> // Mimics fread<br> size_t OggRead(void *ptr, size_t size, size_t nmemb, void *datasource)<br>
{<br> StreamInfo *si = (StreamInfo *)datasource;<br> RawOggData &raw_ogg = *si->raw_ogg;<br> size_t bytes_to_copy = std::min(nmemb*size, raw_ogg.size() - si->pos);<br> memcpy(ptr, &raw_ogg[si->pos], bytes_to_copy);<br>
si->pos += bytes_to_copy;<br> return bytes_to_copy;<br> }<br><br> // Mimics fseek<br> int OggSeek(void *datasource, ogg_int64_t pos, int whence)<br> {<br> StreamInfo *si = (StreamInfo *)datasource;<br>
if(whence == SEEK_SET)<br> {<br> si->pos = int(pos);<br> }<br> else if(whence == SEEK_CUR)<br> {<br> si->pos += int(pos);<br> }<br> else if(whence == SEEK_END)<br>
{<br> si->pos = int(si->raw_ogg->size() + pos);<br> }<br> return 0;<br> }<br><br> // Mimics fclose<br> int OggClose(void *)<br> {<br> // Nothing to do<br> return 0;<br>
}<br><br> // Mimics ftell<br> long OggTell(void *datasource)<br> {<br> StreamInfo *si = (StreamInfo *)datasource;<br> return si->pos;<br> }<br><br>}<br><br><br>-I wasn't sure how many people still use this. I'm glad at least one person does. I just happened to find it. Thanks for the help and I'll see if I can use one of those debuggers.<br>
<br><div class="gmail_quote">On Sun, May 27, 2012 at 1:43 AM, William Ahern <span dir="ltr"><<a href="mailto:william@25thandclement.com" target="_blank">william@25thandclement.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, May 26, 2012 at 11:54:56PM -0400, Ryan Sullivan wrote:<br>
<snip><br>
<div class="im">> occurs. It seems the code is not thread safe and I've tried a bunch of<br>
> things with mutexes or changes to the code but have not had success with<br>
> this so far. The crash will either occur in ov_read or at random points<br>
> within the main thread of the game. (such as doing change animation calls<br>
> or cases where the game won't crash if music isn't using it's own thread)<br>
> I'm going to send basically what I hope to be the only relevant code for<br>
> the music and see if anyone has any suggestions on what I can do to fix<br>
> this problem.<br>
<br>
</div>AFAIK, libvorbis and libogg are passively thread safe in the sense used by<br>
Unix programmers: contexts don't access shared, mutable storage. For Windows<br>
programmers, thread-safe usually means that the library actively uses<br>
mutexes internally so that the same context can be used from multiple<br>
threads out-of-the-box. This is not the case for libvorbis and libogg. You<br>
need to explicitly synchronize use of the API over each object. I don't see<br>
any locking in the code you posted.<br>
<br>
Have you used a debugger? Valgrind, Purify, dbx, etc? Valgrind, for example,<br>
can diganose mutex issues by tracking mutex use and data access among<br>
threads.<br>
<br>
FWIW, this list is pretty much dead. We may be the only ones subscribed and<br>
paying attention.<br>
<br>
</blockquote></div><br>