[gmx-developers] Re: gmx_fatal deadlock bug

[Sander Pronk]

Actually, it's not that hard to prove that mutexed code works - it's just that if not properly isolated, it easily becomes hard to maintain. 

I just checked, and it appears the warning code is only used in grompp, and a few places in gmxlib, where it's being used by mdrun. The question now is: in those instances in mdrun, do we want a global warning count, or is a local one good enough?

Sander


On Jan 29, 2010, at 10:59 , Berk Hess wrote:

> Hi,
> 
> The problem with the current code is that there are no guarantees that
> it won't deadlock.
> This might only appear very infrequently, but it would still be very
> annoying.
> So we or have to test things very thoroughly or at least simply the
> mutex locking a bit,
> for instance by getting git of the global warning variables, which are
> only used by
> two or three programs.
> 
> Berk
> 
> David van der Spoel wrote:
>> On 1/29/10 10:40 AM, Sander Pronk wrote:
>>> The fix looks fine; the only weird thing I see is the 'if
>>> (msg==NULL)' check in _gmx_error.
>>> I haven't seen gmx_fatal deadlock yet: what triggered it?
>>> 
>>> In general, gmx_fatal.c and futil.c contain many ugly hacks that need
>>> to go away. Especially futil.c with its dependence on a global list
>>> of open files/pipes, and its interlocking function calls, is a
>>> constant source of deadlocks or thread safety issues whenever someone
>>> wants to change something. The only real way to fix this is to change
>>> the interface to the rest of the code.
>>> The sheer amount of work involved in changing APIs that are called by
>>> most of the code in Gromacs has kept me from doing it now, however.
>>> Perhaps it's best to wait for the 5.0 branch.
>>> 
>> I plead guilty.
>> 
>> However in the case of file I/O it is not so hopeless, even though
>> someone will have to do emacs *.c. If the file I/O routines would
>> return an abstract type rather than an integer we could get rid of the
>> global variables. The compiler will be able to help to fix most
>> problems. But it is definitely after 4.1.
>> 
>> 
>>> Sander
>>> 
>>> 
>>> On Jan 28, 2010, at 20:05 , Szilárd Páll wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I have recently committed a bugfix for gmx_fatal.c that fixes a
>>>> deadlock we traced and fixed with Berk this afternoon. Basically the
>>>> debug_mutex (which, to be honest, I don't know what exactly is) was
>>>> used in locking more then one resource in different functions that
>>>> happened to call each other.
>>>> 
>>>> The reason I am writing is that there might still be some situations
>>>> in which problems might occur and it seems that gmx_fatal would need a
>>>> bit of checking and rewriting. I am not so familiar with the code so I
>>>> thought I let you know about the issue; I also left a couple of
>>>> comment where I was not sure what to do.
>>>> 
>>>> Best regards,
>>>> -- 
>>>> Szilárd
>>> 
>> 
>> 
> 
> -- 
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the 
> www interface or send it to gmx-developers-request at gromacs.org.