• Wan-Teh Chang's avatar
    pthread_frame: use better memory orders for frame progress · 343e2833
    Wan-Teh Chang authored
    This improves commit 59c70227.
    
    In ff_thread_report_progress(), the fast code path can load
    progress[field] with the relaxed memory order, and the slow code path
    can store progress[field] with the release memory order. These changes
    are mainly intended to avoid confusion when one inspects the source code.
    They are unlikely to have measurable performance improvement.
    
    ff_thread_report_progress() and ff_thread_await_progress() form a pair.
    ff_thread_await_progress() reads progress[field] with the acquire memory
    order (in the fast code path). Therefore, one expects to see
    ff_thread_report_progress() write progress[field] with the matching
    release memory order.
    
    In the fast code path in ff_thread_report_progress(), the atomic load of
    progress[field] doesn't need the acquire memory order because the
    calling thread is trying to make the data it just decoded visible to the
    other threads, rather than trying to read the data decoded by other
    threads.
    
    In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
    atomic_init().
    Signed-off-by: 's avatarWan-Teh Chang <wtc@google.com>
    Signed-off-by: 's avatarAnton Khirnov <anton@khirnov.net>
    343e2833
pthread_frame.c 25.6 KB