[Vorbis-dev] Thread Problem.

[Ryan Sullivan]

Thanks for the response.

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.

"This is not the case for libvorbis and libogg. You
need to explicitly synchronize use of the API over each object. I don't see
any locking in the code you posted."

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.

Here's some of the code I left out before:

const ov_callbacks my_callbacks = {
        OggRead,
        OggSeek,
        OggClose,
        OggTell
    };

    // Mimics fread
    size_t OggRead(void *ptr, size_t size, size_t nmemb, void *datasource)
    {
        StreamInfo *si = (StreamInfo *)datasource;
        RawOggData &raw_ogg = *si->raw_ogg;
        size_t bytes_to_copy = std::min(nmemb*size, raw_ogg.size() -
si->pos);
        memcpy(ptr, &raw_ogg[si->pos], bytes_to_copy);
        si->pos += bytes_to_copy;
        return bytes_to_copy;
    }

    // Mimics fseek
    int OggSeek(void *datasource, ogg_int64_t pos, int whence)
    {
        StreamInfo *si = (StreamInfo *)datasource;
        if(whence == SEEK_SET)
        {
            si->pos = int(pos);
        }
        else if(whence == SEEK_CUR)
        {
            si->pos += int(pos);
        }
        else if(whence == SEEK_END)
        {
            si->pos = int(si->raw_ogg->size() + pos);
        }
        return 0;
    }

    // Mimics fclose
    int OggClose(void *)
    {
        // Nothing to do
        return 0;
    }

    // Mimics ftell
    long OggTell(void *datasource)
    {
        StreamInfo *si = (StreamInfo *)datasource;
        return si->pos;
    }

}


-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.

On Sun, May 27, 2012 at 1:43 AM, William Ahern
<william at 25thandclement.com>wrote:

> On Sat, May 26, 2012 at 11:54:56PM -0400, Ryan Sullivan wrote:
> <snip>
> > occurs. It seems the code is not thread safe and I've tried a bunch of
> > things with mutexes or changes to the code but have not had success with
> > this so far. The crash will either occur in ov_read or at random points
> > within the main thread of the game. (such as doing change animation calls
> > or cases where the game won't crash if music isn't using it's own thread)
> > I'm going to send basically what I hope to be the only relevant code for
> > the music and see if anyone has any suggestions on what I can do to fix
> > this problem.
>
> AFAIK, libvorbis and libogg are passively thread safe in the sense used by
> Unix programmers: contexts don't access shared, mutable storage. For
> Windows
> programmers, thread-safe usually means that the library actively uses
> mutexes internally so that the same context can be used from multiple
> threads out-of-the-box. This is not the case for libvorbis and libogg. You
> need to explicitly synchronize use of the API over each object. I don't see
> any locking in the code you posted.
>
> Have you used a debugger? Valgrind, Purify, dbx, etc? Valgrind, for
> example,
> can diganose mutex issues by tracking mutex use and data access among
> threads.
>
> FWIW, this list is pretty much dead. We may be the only ones subscribed and
> paying attention.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20120527/5ce6f69c/attachment-0001.htm