Avoid calling twice into opal_mutex_lock() in ompi_mpi_instance_init()

[janciesko]

Avoid deadlock by calling opal_mutex_lock twice on same thread. Since ompi_mpi_instance_init_common is called only from ompi_mpi_instance_init, this refactor should be otherwise equivalent.

[ompiteam-bot]

Can one of the admins verify this patch?

[devreal]

ok to test

[devreal]

I'm not sure if this is connected to your patch but there seem to be instances where the instance_lock is released twice:

• ompi/ompi/instance/instance.c

  Line 1050 in 4f604e7

  opal_mutex_unlock (&instance_lock);

• ompi/ompi/instance/instance.c

  Line 815 in 4f604e7

  opal_mutex_unlock (&instance_lock);

instance_lock is a recursive lock and the title makes it sound like you're removing lock calls...

[janciesko]

Good point, the PR might se side stepping the issue then. It might be that the recursive lock does not work. Currently, this sequence deadlocks.

opal_mutex_lock(&instance_lock);
opal_mutex_lock(&instance_lock);

[gpaulsen]

@janciesko What's your plan with this PR?

[janciesko]

This error is specific to the Qthreads ULT support - currently Qthreads does not support recursive mutex. The correct fix seems to be to add recursive mutex support to Qthreads. This would avoid the deadlock in ompi for that sequence of lock acquisitions.

[janciesko]

We can close this PR and I will open a new PR with the updated calls to Qthreads recursive locking.