Boost logo

Boost :

From: (noreply_at_[hidden])
Date: 2005-09-02 12:06:27

Support Requests item #1280829, was opened at 2005-09-02 10:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multithreaded process pausing but not deadlocking or crashin

Initial Comment:

I am writing a largely multithreaded linux program (20-60
threads) on version Fedora Core 2. I am using glib c
version 2.3.3-27. In addition, I am using the boost
libraries (version 1.32.0) for my threading and locking.
Specifically, I am using mutexes, recursive_mutexes,
scoped locking, and conditions.

My problem is that the process will suddenly cease
activity for random lengths of time (1 sec to minutes).
However, it never crashes or produces incorrect results.
Also, I do not think that it is deadlocking because it
always resumes its activity.

I have done some profiling of the locks, and it shows
very strange behavior. For instance, threads will block
for long lengths of time (the length of the inactivity) while
no thread is holding the corresponding mutex more than
fractions of a second. When I explored this further, it
appears that thread A is blocking on a mutex while
thread B holds it. I am using
boost::recursive_mutex::scoped_lock objects for the
locking. The weird thing is that thread B pauses at the
very end of the lock's scope (again for a the length of
inactivity), as though the attempt to unlock the mutex is
not waking thread A and descheduling thread B for a
long time.

I created a test program that spawns 30 threads that
just do a bunch of locking of these boost scoped locks
and yielding. This program, too, shows the same
downtime activity (again without crashing or
deadlocking), though less frequently (I suspect because
the locking pattern is probably different than in my
program). It also always resumes its activity eventually.
I have attached the test program code.

I'm not sure whether this is a problem with the boost
libraries or a linux problem, or my own problem.

I was wondering if anyone has experienced similar
behavior and might be able to offer some insight or
guidance. Thanks!



You can respond by visiting:

SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement *
Boost-bugs mailing list

Boost list run by bdawes at, gregod at, cpdaniel at, john at