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 <[email protected]> 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 > > [email protected] > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
