I’ll answer this myself:

When esl_mutex_t  is created in esl_mutex_create(), attribution “PTHREAD_MUTEX_RECERSIVE” is set.

This attribution allows mutex is locked for several times without unlock in the same thread.

So there is no dead lock issue for esl_execute()

But I still meet another dead lock between main thread (sending ESL cmd) and ESL event process thread, is there any constrain for esl interface usages in *INBOUND* mode under multi-thread?

>>>>>>>>>

esl_execute()

When I read the implementation of the code,  is there any possibility to dead lock as following?

esl_execute()

    +-->esl_send_recv /esl_send_recv_timed(_handle, _cmd, 0)

         +--> esl_mutex_lock(handle->mutex);        <<<<< lock for 1^st time

                +--> esl_recv_event_timed(handle, ms, 0, &handle ->last_sr_event)

                     +--> esl_recv_event()

                         +----> esl_mutex_lock(handle->mutex);  <<<<<< lock for 2^nd time, but preview one is not unlock