Subj : Re: Freeing data structures in a threaded application
To   : comp.programming.threads
From : David Schwartz
Date : Wed Feb 16 2005 08:36 am


"Luke Ehresman" <lehresma@gmail.com> wrote in message 
news:1108567442.837973.137640@c13g2000cwb.googlegroups.com...

> I think I've come up with a solution.  The full problem is that I could
> have references to the session in three threads (session manager, cache
> manager, and the connection handler).  When a user connects, the
> connectio handler attaches to that user's session.  Connections come
> and go very frequently, but the session is the persistance between
> connections (much the same way that sessions work in PHP or JSP).
> Currently I did not lock the session for the whole duration of the
> connection, but only for individual operations within the connection.
> I think that if I lock the session when a connection begins, and unlock
> it right after the connection ends, this will be a better way of
> handling it.  That way there is no threat of the session being deleted
> while a connection still has a reference to it.

    It depends what you mean by "lock the session". If you mean actually 
hold a mutex, NO, don't do that. If you mean set some 'locked' flag in the 
session structure that tells other threads not to delete it, then that's 
fine.

> This will work because two connections cannot access the same session.
> I originally was trying to avoid this because the connection could hold
> the lock on the session for several seconds, and nothing else would be
> able to operate on it.  But really, the only time I want the cache
> manager to operate on the session is when there is no connection
> attached to it.

    I guess you could use a 'trylock' function in the cache manager. But you 
get back to the same problem, you have to protect the list of all sessions 
that the cache manager uses.

> Then I will also use the method you proposed to protect the cache
> manager thread from operating on a freed session.
>
> Thanks for helping me clear my thoughts on the issue.  I'm not new to
> threaded programming, but have never written an application that uses
> threads so intensively before.

    Good luck. You have to make every mistake once, I'm afraid. Perhaps if 
you're lucky, it'll be just once. ;)

    DS

.