This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: deadlock detection


I've been trolling through the entire gcc code, and can't seem to find
generic containers anywhere. I also haven't seen anything that refers to
what is and what isn't suitable to use as far as external libraries or
code. So with that said, is it ok to use the stl when hacking on the
runtime? I guess for my personal enjoyment it's fine, but I'd like to
actually contribute a patch at some point.

My current approach would to be instrument the _Jv_MutexLock routine in
posix-threads.h. Since we can tell from the _Jv_Mutex_t structure
whether we are going to go into a wait state before calling 
pthread_mutex_lock. At this point, if we know a wait state is about to
occurr, an edge would be added to the wait-for-graph And then removed
once the call returns.

I've also had some discussions with people indicating the the edges
could also contain a state indicating whether it's currently active or
was active at some point in the past. This would allow a check to see if
an actual deadlock exists, and if the possibility of a deadlock
occurring at some point in the future could happen.


thanks
-jake



On Thu, 2003-09-11 at 13:12, Andrew Haley wrote:
> Jacob Gladish writes:
>  > I've implemented a small simulation of a Wait For Graph that I'd like to
>  > fit into the current runtime,
> 
> Cool.
> 
>  > but I'm unsure of what data structures to use. My current
>  > implementation uses the stl, since it was easy and quick to nail
>  > the algorithm down. I'm not sure what data structures to use when
>  > putting this into the runtime. Is it ok to use the collections from
>  > java::util?
> 
> Perhaps, but maybe java::util uses locks, and if so locks can't use
> java::util.
> 
>  > What I currently have planned is to add hooks into the
>  > _Jv_MonitorEnter/_Jv_MonitorExit calls to adjust the graph state,
>  > and the finalize_native to remove any thread entries from the
>  > graph. Is it ok to reference the collections from this level or do
>  > new data structures need to be written from scratch?
> 
> There's no law against it, but you must make very very sure that the
> collections classes you use don't call _Jv_MonitorEnter.  I don't
> think you can guarantee that, because class initialization acquires a
> lock.  Tricky.
> 
> Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]