Skip to main content

[Migrated content. Thread originally posted on 22 October 2004]

We have been getting the "Receive/Wait in locked thread - deadlocked" error lately at random times in our programs. We use threading in all of our reports and most of the time we don't have a problem but occasionally we get these deadlock errors. We have lock and unlock thread statements in both threads of the report but I am pretty confident that once the thread gets to the "wait for last thread" statement, it has been unlocked. The funny thing is that it didn't happen for a long time and then has really started happening alot lately.

After investigating it a bit, it seems like something else is executing a lock thread outside of our own source code.

Is there a way to figure out where this lock thread that the receive/wait was complaining about came from or some way of viewing the lock thread stack so I can watch the lock threads get executed to try to debug this?

Thanks for any help you can give.

Dan Preece
Infotrax Systems

[Migrated content. Thread originally posted on 22 October 2004]

We have been getting the "Receive/Wait in locked thread - deadlocked" error lately at random times in our programs. We use threading in all of our reports and most of the time we don't have a problem but occasionally we get these deadlock errors. We have lock and unlock thread statements in both threads of the report but I am pretty confident that once the thread gets to the "wait for last thread" statement, it has been unlocked. The funny thing is that it didn't happen for a long time and then has really started happening alot lately.

After investigating it a bit, it seems like something else is executing a lock thread outside of our own source code.

Is there a way to figure out where this lock thread that the receive/wait was complaining about came from or some way of viewing the lock thread stack so I can watch the lock threads get executed to try to debug this?

Thanks for any help you can give.

Dan Preece
Infotrax Systems
Originally posted by danielp37
After investigating it a bit, it seems like something else is executing a lock thread outside of our own source code.


Note that ACUCOBOL-GT multithreading is proprietary to ACUCOBOL-GT. This means if something 'outside' should lock, it must be written in ACUCOBOL-GT too, is that the case?

[Migrated content. Thread originally posted on 22 October 2004]

We have been getting the "Receive/Wait in locked thread - deadlocked" error lately at random times in our programs. We use threading in all of our reports and most of the time we don't have a problem but occasionally we get these deadlock errors. We have lock and unlock thread statements in both threads of the report but I am pretty confident that once the thread gets to the "wait for last thread" statement, it has been unlocked. The funny thing is that it didn't happen for a long time and then has really started happening alot lately.

After investigating it a bit, it seems like something else is executing a lock thread outside of our own source code.

Is there a way to figure out where this lock thread that the receive/wait was complaining about came from or some way of viewing the lock thread stack so I can watch the lock threads get executed to try to debug this?

Thanks for any help you can give.

Dan Preece
Infotrax Systems
That is what I mean. Is there something within the runtime that will lock a thread besides the lock thread statement? And more importantly, is there some way of turning on tracing or something so that I can see when threads are getting locked an unlocked?

[Migrated content. Thread originally posted on 22 October 2004]

We have been getting the "Receive/Wait in locked thread - deadlocked" error lately at random times in our programs. We use threading in all of our reports and most of the time we don't have a problem but occasionally we get these deadlock errors. We have lock and unlock thread statements in both threads of the report but I am pretty confident that once the thread gets to the "wait for last thread" statement, it has been unlocked. The funny thing is that it didn't happen for a long time and then has really started happening alot lately.

After investigating it a bit, it seems like something else is executing a lock thread outside of our own source code.

Is there a way to figure out where this lock thread that the receive/wait was complaining about came from or some way of viewing the lock thread stack so I can watch the lock threads get executed to try to debug this?

Thanks for any help you can give.

Dan Preece
Infotrax Systems
There are situations were a thread will block unintentionally, f.ex if calling Windows API or using c$socket.

As for tracing, I am afraid we don't have any such mechanism.

Implementing a tracer for this on your own should however not be that difficult, it is just a matter of writing something to a file.

[Migrated content. Thread originally posted on 22 October 2004]

We have been getting the "Receive/Wait in locked thread - deadlocked" error lately at random times in our programs. We use threading in all of our reports and most of the time we don't have a problem but occasionally we get these deadlock errors. We have lock and unlock thread statements in both threads of the report but I am pretty confident that once the thread gets to the "wait for last thread" statement, it has been unlocked. The funny thing is that it didn't happen for a long time and then has really started happening alot lately.

After investigating it a bit, it seems like something else is executing a lock thread outside of our own source code.

Is there a way to figure out where this lock thread that the receive/wait was complaining about came from or some way of viewing the lock thread stack so I can watch the lock threads get executed to try to debug this?

Thanks for any help you can give.

Dan Preece
Infotrax Systems
There are situations were a thread will block unintentionally, f.ex if calling Windows API or using c$socket.

As for tracing, I am afraid we don't have any such mechanism.

Implementing a tracer for this on your own should however not be that difficult, it is just a matter of writing something to a file.
Terms & ConditionsAccessibility statement