From: Michael Elizabeth Chastain <mec@shout.net>
To: fredrik@dolda2000.cjb.net
Cc: gdb@sources.redhat.com
Subject: Re: Checking function calls
Date: Fri, 06 Dec 2002 09:08:00 -0000 [thread overview]
Message-ID: <200212061708.gB6H8BS01208@duracef.shout.net> (raw)
Hi Fredrik,
> It is a GNU/Linux platform, and, yes, I am using gcc.
Well, that wraps up that line of inquiry.
> I know, I didn't plan ahead good enough when I started writing it, and
> now I'm stuck with either this, or a large rewrite.
When I run into this kind of problem, I like to step back -- way back --
get away from computers for a day or two and think about it.
I think there is no easy way out, that you actually are stuck with a
large rewrite. There are just too many pthread_mutex_lock's flying
around.
For instance:
client.c:findtransfer() does not have any locks.
in client.c:freesharecache(), there is code:
if (cache->parent != NULL)
{
pthread_mutex_lock(&cache->parent->mutex)l;
...
}
in general, it's unsafe to test a member and then acquire the lock,
because someone else can delete cache->parent between the "if" statement
and the acquisition of the lock.
In client.c:clientmain():
for(cur = transfers; cur != NULL; cur = next)
{
pthread_mutex_lock(&cur_mutex);
next = cur->next;
...
}
between the execution of "cur = transfers" and "cur != NULL",
the first item of the list can be deleted.
I recommend finding a textbook on multi-threaded programming that covers
"how to write thread-safe lists". From your package, it looks like
you are in it to learn, so you could step way back from the code and
learn some theory at this point.
Another alternative is to use one big mutex for the whole list.
Then the primitive operations become:
add item to list
lock the whole list
add the item
unlock the whole list
delete item from list
lock the whole list
delete the item
unlock the whole list
iterate over the list
lock the whole list
iterate over all the items
unlock the whole list
The drawback is that walking the list locks the whole list against
addition and deletion. If your list walker is just "print status
information" then that is fine. If your list walker does some
long-lived network operation at each node then it is not fine.
Michael C
next reply other threads:[~2002-12-06 17:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-06 9:08 Michael Elizabeth Chastain [this message]
2002-12-06 11:31 ` Fredrik Tolf
[not found] <200212052240.gB5Mefm16249@duracef.shout.net>
2002-12-06 8:24 ` Fredrik Tolf
-- strict thread matches above, loose matches on Subject: below --
2002-12-04 20:51 Michael Elizabeth Chastain
2002-12-05 15:14 ` Fredrik Tolf
2002-12-04 18:02 Fredrik Tolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200212061708.gB6H8BS01208@duracef.shout.net \
--to=mec@shout.net \
--cc=fredrik@dolda2000.cjb.net \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox