tree b6536be965f31a86351a87f4e722c92bfb04e69a
parent 65e86fce1fe9e3f9aff98861c5e1e9d9ba6df9d5
author Martijn Coenen <maco@google.com> 1362186945 -0800
committer Martijn Coenen <maco@google.com> 1362531996 -0800

Fix some LLCP threading issues.

On Android we now start connecting SNEP/other LLCP
services as soon as the link comes up. That means
we will have connect requests incoming, accept
responses outgoing, connect requests outgoing and
accept responses incoming.

This lays bare a lot of threading issues in this lib.
Since the receives come in serialized, those typically
do not cause any issue. However, we may be sending
something on a thread coming from the NfcService,
while at the same time we'll receive for example
a connect frame from the remote, to which the receive
thread immediately wants to send a response.

This is a first attempt at making sends thread-safe:
already there was a lot of logic to deal with the fact
that another send was in progress, in the form of the
bSendPending variable. That variable was however
not checked atomically, and some operations did not
even set it correctly.

This change tests and sets that variable atomically,
more or less implementing a semaphore with try-acquires
and fallbacks for the failure case.

The generic structure is:

if (testAndSetSendPending()) {
   // Another thread is sending, stash data
   // and most importantly do *NOT* change shared data
} else {
   // We're now the only one sending, we're free
   // to change shared data until the callback is
   // called.
}

This is just a band-aid fix, but given the fact that
this stack will be deprecated it is hopefully enough
for our planned usecases.

A decent fix would involve switching to
a TX-queue per socket, and a generic TX-queue
for the whole LLCP link. This allows us to fully
decouple the connection layer from the transport
layer, as it should be.

Change-Id: Ibd8742f7350a58459771f5036a049af3a487f783