> On Oct 9, 2018, at 2:44 PM, Alan Carroll <solidwallofc...@oath.com.INVALID>
> wrote:
>
> 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.
Right. I think the example (below) makes sense if the critical_section() is
blocking for example (for longish times). And then you can schedule that work
on the “task” threads I think (and make sure you have enough of those thread).
Cheers,
— leif
>
> 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
