But these are not inherently purposes. I could decide there needed to
be a special thread to execute all functions with the letter r in the
name. But that would arbitrary, not an actual purpose. Generally
speaking, in an event driven system, you only need different threads
for multiple cores and
I thought the purpose of the different threads in ATS was pretty clear.
There are many threads to handle requests (1.5x the number of HT cores).
8 threads to handle disk I/O (cache).
2-3 threads to do miscellaneous tasks.
2-3 threads to handle logging.
One thread for each port which you want to lis
Unfortunately that's like many of our explanations, too open-ended to
be very helpful when someone sits down to write some code.
On Wed, Oct 10, 2018 at 2:26 PM Alan Carroll
wrote:
>
> To accomodate different behavior requirements on the continuations
> scheduled on a thread in that pool. E.g. non
To accomodate different behavior requirements on the continuations
scheduled on a thread in that pool. E.g. non-blocking vs. blocking for one.
On Wed, Oct 10, 2018 at 2:25 PM Walt Karas wrote:
> Why do we need thread pools?
> On Wed, Oct 10, 2018 at 2:17 PM Alan Carroll
> wrote:
> >
> > Yes, th
Why do we need thread pools?
On Wed, Oct 10, 2018 at 2:17 PM Alan Carroll
wrote:
>
> Yes, that's not well developed. However, it is the reason TS mutexes are
> shareable. If there is a resource shared between continuations the TS
> approach is to have those continuations share the same mutex leadi
Yes, that's not well developed. However, it is the reason TS mutexes are
shareable. If there is a resource shared between continuations the TS
approach is to have those continuations share the same mutex leading to
natural rescheduling for lock contention. In addition, that TS mutexes are
recusive
On Wed, Oct 10, 2018 at 1:35 PM Leif Hedstrom wrote:
>
>
>
> > On Oct 10, 2018, at 11:31 AM, Walt Karas wrote:
> >
> > It seems like ATS does not have a coherent strategy for threading and
> > mutexes.
> >
> > One pure strategy is event driven with one thread per core (processing
> > an event qu
> On Oct 10, 2018, at 11:31 AM, Walt Karas wrote:
>
> It seems like ATS does not have a coherent strategy for threading and mutexes.
>
> One pure strategy is event driven with one thread per core (processing
> an event queue). Share data structures are owned by a particular core
> (also help
It seems like ATS does not have a coherent strategy for threading and mutexes.
One pure strategy is event driven with one thread per core (processing
an event queue). Share data structures are owned by a particular core
(also helps with NUMA), and events that want to access the data
structure are
I think Alan is referring to the below code.
It's a try lock, so if it doesn't succeed it's just rescheduled for later.
void
EThread::process_event(Event *e, int calling_code)
{
ink_assert((!e->in_the_prot_queue && !e->in_the_priority_queue));
MUTEX_TRY_LOCK_FOR(lock, e->mutex, this, e->contin
By explicit continuation locking, I mean code like your example -
before();
TSMutexLock(mutex);
critical_section();
TSMutexUnlock(mutex);
after();
The call to TSMutexLock() is an explicit lock of the mutex. It address the
issue by noting that it rarely, if ever, comes up. However what you suggest
To what "explicit continuation locking" do you refer?
How does this address the issue that using TSMutexLock() or MutexLock
in a currently running continuation function (unnecessarily) blocks
all other events waiting in a thread event queue? Whereas the
inability to lock a continuation mutex caus
> On Oct 9, 2018, at 2:44 PM, Alan Carroll
> 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
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 handle
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
15 matches
Mail list logo
