On 12/14/11 10:28 AM, John Plevyak wrote:
The old locking system was based on TryLocks which could not be taken
forceably. Moreover it depended on
very subtle knowledge of which bits of the various data structures where
protected by which locks. This is clearly
not sustainable, nor is it necessary any longer. Modern threading systems
work well with larger numbers of threads
and fine grain locking.
So, let's change to the more conventional model with fine grained locks
which protect data structures which are
clearly labeled with the lock that protects them and have external APIs
which enforce that protection. These
locks will be just taken in the standard manner, and we will have to ensure
that the data structures are
sliced so as to minimize lock contention in the standard manner.
Let's also have a "Transaction" object (essentially our current Mutex with
additional tracking and book keeping)
and an explicit mechanism for associating resources owned by Processors
(e.g. NetVC) with a Transaction and for passing
resources (e.g. a NetVC) from one Transaction to another and for returning
the resource to the Processor when it is no longer required
(close/free/release). We can also use proxy smart pointers and
encapsulation in debug mode to test that the ownership rules are being
obeyed correctly and that "stale" pointers are not being accessed (i.e.
after the resource has been released).
This sounds like a great idea! How do we get there? This would be a pretty
significant undertaking, and touches pretty much all code. So, perhaps this
is a target goal for v4.0? It sounds like we might need to try to have a
"hackathon" event again somewhere? :)
I believe that the problems we are currently seeing turn on an even more
subtle issue when the ownership of a NetVC
is passed from one transaction to another via the session manager.
Getting that code to work stably required many
a careful negotiation and resulted in something which is clearly very
brittle and not maintainable.
Hopefully we can figure it out to at least make it not crash in the short
term? I could quite possible be at fault here too, I added extra complexity
by adding an (optional) per thread session pool. I hope that is not causing
some of these problems?
Cheers,
-- leif
