[CinCV TNG] lock problems with suse/leap, which can cause segvs in 5.1

Good Guy good1.2guy at gmail.com
Sun Nov 6 23:02:58 CET 2016

> Perhaps the mutexes should be changed to recursive?

from guicast mutex.C (cin5.1):

int Mutex::unlock()
        if( count <= 0 ) {
                printf("Mutex::unlock not locked: %s\n", title);
                return 0;
// Remove from recursive status

Mutex locks can be recursive, or not, already...

As it turns out, intel's lock elision code was causing SEGVs when
attempting to unlock a locked mutex.  Since intel seems to be now
disavowing TSX locks in the microcode updates, I am not sure that this is
not a really issue, unless you have real evidence that there is a problem.

Have you run 'valgrind --tool=helgrind' and actually seen problems??


On Sun, Nov 6, 2016 at 2:50 PM, Petter Reinholdtsen <pere at hungry.com> wrote:

> A discussion about this locking problem came up yesterday in Debian, see
> <URL: https://lists.debian.org/debian-devel/2016/11/msg00210.html >.
> It is worth noting that the general concensus there is that code trying
> to unlock a non-locked mutex is wrong and should be fixed.  On Linux
> machines with CPUes without TSX would ignore such errors, while Linux
> running on recent Intel CPUs for x86 and the s390(x) architecture would
> crash.  The crash would also happen on Debian systems using the Hurd and
> kFreeBSD kernels.
> Personally I am conviced the proper and long term fix for this is to
> make sure pthread mutexes are used without undefined behaviour.  Sooner
> or later the incorrect use of mutexes will affect us all. :)
> Perhaps the mutexes should be changed to recursive?  See
> <URL: http://pubs.opengroup.org/onlinepubs/9699919799/
> functions/pthread_mutex_unlock.html >
> for the POSIX description of pthread_mutex_*() functions, to get an idea
> about what the standard specifies.
> Notice how 'valgrind --tool=helgrind' can be used to discover these
> mutex errors also on machines without TSX support.
> --
> Happy hacking
> Petter Reinholdtsen
> _______________________________________________
> Cinelerra mailing list
> Cinelerra at lists.cinelerra-cv.org
> http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cinelerra-cv.org/pipermail/cinelerra/attachments/20161106/87a7bd10/attachment.html>

More information about the Cinelerra mailing list