It's a bit more complex than that. One key thing is that if you schedule an
event for a continuation, when the event handler is called the continuation
mutex will be locked. Therefore it's rarely the case a plugin needs to lock
its continuations explicitly. For that reason, simply scheduling handles
lock contention without thread blocking.
In the core, there is a class, MutexLock, which does the RAII style locking.
On Tue, Oct 9, 2018 at 2:26 PM Walt Karas <wka...@oath.com.invalid> wrote:
> In TS, is it important to favor use of continuation mutexes to avoid
> thread blocking. For example, should code like this:
>
> before();
> TSMutexLock(mutex);
> critical_section();
> TSMutexUnlock(mutex);
> after();
>
> be replaced with code like:
>
> int contf_after(TSCont, TSEvent, void *)
> {
> after();
>
> return 0;
> }
>
> int contf_critical_section(TSCont, TSEvent, void *)
> {
> critical_section();
>
> static TSCont cont_after = TSContCreate(contf_after, nullptr);
>
> TSContSchedule(cont_after, 0, TS_THREAD_POOL_DEFAULT);
>
> return 0;
> }
>
> // ...
>
> before();
>
> static TSCont cont_critical_section =
> TSContCreate(contf_critical_section, mutex);
>
> TSContSchedule(cont_critical_section, 0, TS_THREAD_POOL_DEFAULT);
>
> // ...
>
> (This is plugin code but I assume the same principle would apply to core
> code.)
>
--
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28
