Hi All, Recently I'm writing an Application with ESL in inbound mode. I have two issues: 1) esl_recv_event() a) Each time I call this interface, handle->last_ievent will be updated to be the oldest event. Just like de-queue the oldest event from FIFO. My assumption is right or not? b) After call this interface, may I access "handle->last_ievent" without any protection( without mutex/lock)? If there is any risk of handle->last_ievent is updated during my access, for example some other interfaces are called or new events are received from FS side. Per my experience, seems has such risk. 2) 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 1st time +--> esl_recv_event_timed(handle, ms, 0, &handle ->last_sr_event) +--> esl_recv_event() +----> esl_mutex_lock(handle->mutex); <<<<<< lock for 2nd time, but preview one is not unlock Can anyone confirm this? BR Leon
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 1st time +--> esl_recv_event_timed(handle, ms, 0, &handle ->last_sr_event) +--> esl_recv_event() +----> esl_mutex_lock(handle->mutex); <<<<<< lock for 2nd time, but preview one is not unlock
participants (1)
-
leonhe