Hey Sven,
you are right, this might be indeed a problem. I'll send an updated patch which removes the problem by employing atomic_add_unless().
Marek also pointed out that global variables are not very pretty as we are moving all the global stuff into bat_priv to allow multiple mesh soft interfaces later. However I'd first send the patch with globals as is and move them later in another patch.
best regards, Simon
On Mon, Apr 05, 2010 at 01:21:36PM +0200, Sven Eckelmann wrote:
It should be possible to have multiple events accessing these functions at the same time, or am I wrong?
Just say we have following situation (queue is full; full == 1):
- bcast comes in and we start add_bcast_packet_to_list and dec_test(left) == 1 -> damn, no room left for us
-> for easier understanding: someone steals our cpu or the processing is otherwise interleaved with following
- another bcast comes in and wants attention (left is now 0): dec_test(left) == 0 (because left is now -1... or 0xfff....fff). Lets enqueue it and do the rest
- first bcast continues and and does atomic_inc(left) -> now it is 0
- now a storm of bcasts comes in and all do atomic_dec_and_test... each one will be accepted because left is already zero and needs a looooong time to be 0 again (or enough bcast packets were processed from the queue to get positive again)
I am not 100% sure if this really can happen, but I thought that it was a hard requirement for TCP port passed processor selection for parallel processing of incoming packets on multicore/multiprocessor architectures.
Best regards, Sven