The deadlock happens when matlab
- loads a shared object (or library)
- AND the shared object executes some initialization code (e.g., constructors of global objects defined in the library)
- AND the initialization code calls 'pthread_join()'. 'pthread_join()' then never returns.
Note that if 'ordinary' code in the shared object (i.e., as opposed to initialization code) uses 'pthread_join()' then
that works fine.
EPICS' libCom does use 'pthread_join()' during initialization and is therefore affected.
At this point I can suggest two possible work-arounds (using one of them is sufficient):
1.) Use an EPICS-base build with posix priority scheduling disabled. This avoids a section of initialization
code which calls 'pthread_join()'
The init code that Till is referring to has been in osi/os/posix/osdThread.c since 2011:
staticvoid findPriorityRange(commonAttr *a_p)
{
priAvailable arg;
pthread_t id;
void *dummy;
int status;
arg.policy = a_p->schedPolicy;
arg.ok = 0;
status = pthread_create(&id,
0, find_pri_range, &arg);
When posix priority scheduling is enabled this gets called from inside the
once() routine that the Posix epicsThreadInit() implementation runs using pthread_once(). I don’t see an easy way to avoid doing that initialization here;
it might be possible by adding more lazy-init logic to only look up the min and max scheduling priorities when they are actually needed, but I suspect that would still be before the end of the initialization code.
Hence not something we should try to fix IMHO.
- Andrew
--
Complexity comes for free, simplicity you have to work for.