[Click] Handler Synchronization question

Roman Chertov rchertov at cs.ucsb.edu
Fri Feb 25 13:27:56 EST 2011


Thanks Eddie.  I'll give that a shot some time next week, once I get all of my
results.  I also need to make a patch for FromHost as it does not compile on a
patched 2.6.24.7 kernel.  I ended up using the older code for that element.

Roman

On Fri, 25 Feb 2011 10:16:10 -0800 Eddie Kohler <kohler at cs.ucla.edu> wrote

> Hi Roman,
> 
> Fair question, and at first I thought the question was harder than it is.  If
>
> you want to use Handler::NONEXCLUSIVE with locking, try SpinlockIRQ.  I
> believe this will work even when Click is compiled for uniprocessor.
> 
> Eddie
> 
> 
> On 2/11/11 10:27 AM, Roman Chertov wrote:
> > I have a question regarding synchronization between the handlers and the
> > main
> > element code.  As far as I understand, using Handler::NONEXCLUSIVE flag
> > when
> > defining a handler allows for the case where the main thread executes a
> > task for
> > some element, while at the same time the handler for that element can get
> > called.
> >
> > However, the following comment for SpinLock got me confused as to how
> > ensure
> > atomic operations when the element task and the handler execute at the same
> > time.
> >
> >   * Spinlock operations do nothing unless Click was compiled with SMP
> >   support
> >   * (with --enable-multithread).  Therefore, Spinlock should not be used
> >   to,
> >   * for example, synchronize handlers with main element threads.  See also
> >   * SpinlockIRQ.
> >
> > If Spinlock is not the proper mechanism, what is the proper way to do it
> > when
> > building an element that must work in user and kernel levels?
> >
> > Thanks,
> >
> > Roman
> >
> >
> > _______________________________________________
> > click mailing list
> > click at amsterdam.lcs.mit.edu
> > https://amsterdam.lcs.mit.edu/mailman/listinfo/click




More information about the click mailing list