A new idea for garbage collection

[root]

Hi,

This is a followon from my unsuccessful inquiry about getting SIGSEGV
delivered per thread not per process.

Normally the execution flow of many threaded programs will be like

pthread_mutex_lock
do some critical region stuff
pthread_mutex_unlock

So the question is: why doesn't the thread library itself keep track of
the locks acquired by a particular thread, and when threads cancel/exit,
release/unlock all the locks acquired by that thread.

Then even if a programmer writes buggy code, again one thread dying will
not destroy the whole process.

Conceptually it's very much like garbage collection of heap memory, which
is also a great feature IMO (I use Boham's GC for all my C programs).

ATB.

 

[Morris Keesan]

....

So the question is: why doesn't the thread library ...

As you were told last time you asked, C doesn't have a thread library.
You might want to try a threads newsgroup, or if your comment is about
a specific thread library on a specific OS or class of OSes, a newsgroup
relevant to that OS.

 

[Keith Thompson]

This is a followon from my unsuccessful inquiry about getting SIGSEGV
delivered per thread not per process.

Normally the execution flow of many threaded programs will be like

pthread_mutex_lock
do some critical region stuff
pthread_mutex_unlock

So the question is: why doesn't the thread library itself keep track of
the locks acquired by a particular thread, and when threads cancel/exit,
release/unlock all the locks acquired by that thread.

[snip]

I think we told you last time around that standard C has no support
for threads, and that comp.programming.threads would be a better
place for your questions.

 

[user923005]

Hi,

This is a followon from my unsuccessful inquiry about getting SIGSEGV
delivered per thread not per process.

Normally the execution flow of many threaded programs will be like

pthread_mutex_lock
do some critical region stuff
pthread_mutex_unlock

So the question is: why doesn't the thread library itself keep track of
the locks acquired by a particular thread, and when threads cancel/exit,
release/unlock all the locks acquired by that thread.

Then even if a programmer writes buggy code, again one thread dying will
not destroy the whole process.

Conceptually it's very much like garbage collection of heap memory, which
is also a great feature IMO (I use Boham's GC for all my C programs).

You might try comp.programming.threads and comp.programming for
dicussing your ideas.

You might also like to investigate software transactions:
http://en.wikipedia.org/wiki/Software_transactional_memory

Intel has a beta compiler that demonstrates the idea as a built in
property.

 

[root]

As you were told at the time, this is not the proper forum for
thread questions.


<off-topic>

You don't understand the reason for locking. I bet the fallacy of
this newbie numbskull notion is the topic of a FAQ somewhere -- but not
here, so please go away to another forum. And read their FAQ before
posting this silly question; it may help you avoid embarrassment.

</off-topic>

Eric -

I don't have any interest in listening to stupid insults like this post,
whether in this or any other forum.

I'm sorry that some people want to stop discussion of threaded
programming in C just because they don't use it themselves. More and more
programs will be multithreaded as the number of cores in a desktop
machine increases exponentially in coming years, so my advise would be to
get used to it now.

To keep people happy I've cc'd this to comp.programming.threads as
suggested.

 

[Keith Thompson]

I'm sorry that some people want to stop discussion of threaded
programming in C just because they don't use it themselves. More and more
programs will be multithreaded as the number of cores in a desktop
machine increases exponentially in coming years, so my advise would be to
get used to it now.

To keep people happy I've cc'd this to comp.programming.threads as
suggested.

No, nobody suggested cross-posting.

You cross-posted to comp.lang.c and comp.programming.threads, and set
followups back to comp.lang.c. Readers in comp.programming.threads
should be aware of this, and override the Followup-To header if
necessary.

We're not asking you to take this discussion somewhere other than
comp.lang.c because we don't use threads. We're asking you to take
it elsewhere because *standard C doesn't have threads*. You question
isn't about C, so comp.lang.c isn't the right place to ask it.

This isn't just because we here in clc don't want to read
your question; it's because *you'll get better answers* in
comp.programming.threads.

[snip]

 

[Seebs]

I don't have any interest in listening to stupid insults like this post,
whether in this or any other forum.

This is the risk of posting to usenet. Especially posting something that,
I suspect, may not be a completely new thought, and may run into issues
which people have already encountered, thought about, and worked on a bit.

I'm sorry that some people want to stop discussion of threaded
programming in C just because they don't use it themselves.

No one wants to stop that discussion. We just want it to occur somewhere
relevant and appropriate.

C, per se, does not have threads. Some C implementations have threads.
They have wildly different and fundamentally incompatible notion of threads.

More and more
programs will be multithreaded as the number of cores in a desktop
machine increases exponentially in coming years, so my advise would be to
get used to it now.

What makes you think we're not?

Look at it this way: While the question may be mostly academic for many
programmers, it is almost certainly the case that most C programmers have
some kind of interest in sex. That doesn't make sex topical in a C newsgroup.

I do a great deal of work which involves dealing with or thinking about
threads. However, I don't consider them part of C; I consider them part of
a specific environment in which I use C to program, and that distinction is
significant when thinking about portable code.

Fundamentally, thread behavior is a trait of the operating system, not a
trait of C, at least thus far. If C ever acquires a thread model (and I
wouldn't necessarily object to it doing so), then they'll be topical here.
Until then, not so much.

-s

 

[BGB / cr88192]

Hi,

This is a followon from my unsuccessful inquiry about getting SIGSEGV
delivered per thread not per process.

Normally the execution flow of many threaded programs will be like

pthread_mutex_lock
do some critical region stuff
pthread_mutex_unlock

So the question is: why doesn't the thread library itself keep track of
the locks acquired by a particular thread, and when threads cancel/exit,
release/unlock all the locks acquired by that thread.

Then even if a programmer writes buggy code, again one thread dying will
not destroy the whole process.

Conceptually it's very much like garbage collection of heap memory, which
is also a great feature IMO (I use Boham's GC for all my C programs).

errm... it may come as a terrible shock, but there are people around who
develop for OS's other than Linux and friends...


so, going not strictly topical:
be warned that last I looked, Boehm was not safe for multithreaded code
(although this may have changed).

this sort of unlocking can be done if one goes and writes their own thread
wrapper library (say... to not depend on a particular host OS...).


it is also worth noting that the people around here in CLC are also fussy
about things which diverge too far from what is "standard" C (which means,
those portions of C defined in the standards, and not the huge piles of
stuff everyone around has built on top of it...).

it is much like how I can't sit around here and go into the details of the
PE/COFF format as used in Windows DLLs and EXEs, and the specifics of x86
and x64 machine code (REX prefix, ModRM, VEX and XOP, ...).

granted, there are places where these are topical, just not necessarily
here...

(it is actually a great excercise of effort to figure out what to write
about where, in this large space that is usenet...).

 

[Wolfgang Draxinger]

so, going not strictly topical:
be warned that last I looked, Boehm was not safe for multithreaded code

Must have been some time.

(although this may have changed).

So it did. From the Boehm_GC homepage:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/#platforms
| Irix pthreads, Linux threads, Win32 threads, Solaris threads (old style
| and pthreads), HP/UX 11 pthreads, Tru64 pthreads, and MacOS X threads are
| supported in recent versions.


Wolfgang

 

[root]

Point taken. I apologize for the word "numbskull," which
was insulting, and evidence that I allowed exasperation to get the
better of me and provoke me to an immature reaction.

However, I stand by all the other words in my response,
every single one of them. You are asking your question in the wrong
forum, you are pursuing an idea that is fundamentally a bad idea, and
you have omitted to do the basic FAQ-reading that would have explained
the idea's badness.

I have to disagree with those people who say this is not topical.

In my opinion, this question is quite specifically about threaded
programming *in C*, because multithreaded programs in C++ or Java or any
other modern language will deal with this with exceptions. Only C is so
low-level that garbage collection becomes an issue.

That's not what anyone suggested. And since you still haven't
done any FAQ-reading (the comp.programming.threads FAQ explains the
badness of your not-so-new idea in at least three places), I rather
suspect that some embarrassment awaits you.

The comp.programming.threads FAQ is lengthy and poorly indexed,
being mostly a collection of "raw" Q&A posts, but the information
therein will reward patient search. The FAQ's most detailed explanation
of why your idea is bad was written by one of the authors of the POSIX
threading standards, by a guy who quite literally "wrote the book" on
POSIX threading. You would do well to give his writings some attention,
even if you don't care much for mine.

If I've understood, the main argument against my idea is that if a thread
dies while it holds a lock then whatever the lock is protecting may be
left in an inconsistent state.

Sure. But depending on the application, that may be OK.

Let me explain my situation. I'm writing a program that receives queries
that it looks up in a company database. Then it processes the results and
sends back a report. There's a main thread and whenever a request comes
in, a worker thread is spawned to handle it.

The lock is used because the thread writes the query and some statistics
to a log.

Unfortunately there is a problem with certain data that causes a null
pointer dereference. This happens maybe once a day in practise. Having
one bad line per day in the log is really not a significant problem, but
having the whole query server go down *is* really bad.

There must be many similar situations where garbage collection is exactly
what's needed.

 

[Seebs]

I have to disagree with those people who say this is not topical.

Why? Is there a particular quota of being wrong you have to meet for the
week?

In my opinion, this question is quite specifically about threaded
programming *in C*,

But C has no threading model.

Only C is so low-level that garbage collection becomes an issue.

What about assembly? You can certainly write assembly code on most
Unix-like systems that calls out to the pthread library.

On the other hand, there's tons of C systems to which this doesn't apply,
suggesting that it's really about aspects of a particular system's
threading API, rather than about the C language itself.

Unfortunately there is a problem with certain data that causes a null
pointer dereference. This happens maybe once a day in practise. Having
one bad line per day in the log is really not a significant problem, but
having the whole query server go down *is* really bad.

Non-C answer:
I'd probably avoid using threads that are known to be buggy in a
mission-critical server. This is what child processes are for.

C answer:
Don't dereference null pointers.

There must be many similar situations where garbage collection is exactly
what's needed.

Doesn't seem like a solution to the actual problem to me.

But the thing is... The problem is clearly massively outside the scope of
the language. It's not even semantically coherent to talk about this problem
outside a very specific threading model which is neither unique to C nor
universal to C.

-s

 

[user923005]

I have to disagree with those people who say this is not topical.

In my opinion, this question is quite specifically about threaded
programming *in C*, because multithreaded programs in C++ or Java or any
other modern language will deal with this with exceptions. Only C is so
low-level that garbage collection becomes an issue.

Assembly
Forth
Pascal
Fortran
etc.
Are all at the same approximate level as C in this regard.

Have you failed to notice that every operating system has its own
threading libraries (if, indeed, the OS supports threads -- we could
be talking about a toaster IC)?

The threading calls you make in Windows Server 2008 will not look like
the threading calls you make on OpenVMS 8.3 or Solaris or AIX or z/OS.

If (indeed) there were no such groups as comp.programming.threads or
comp.os.linux.networking or comp.os.vms etc., then your post would be
perfectly acceptable. The issue at hand is not whether or not some
programmers using C will access a threading API (indeed, basically ALL
of my programming deals with threading issues, for instance) but
whether or not there are *better* more sharply focused and targeted
areas to discuss threading. C++ is working on a standardized
threading API. When it has been published and accepted into the
standard, then you will have a formal and clearly defined way to
perform threading on any compliant C++ compiler. I do not know if C
has a similar effort (if so, then probably comp.std.c would be more
topical since it is a language proposal at best currently).

If I've understood, the main argument against my idea is that if a thread
dies while it holds a lock then whatever the lock is protecting may be
left in an inconsistent state.

Sure. But depending on the application, that may be OK.

Let me explain my situation. I'm writing a program that receives queries
that it looks up in a company database. Then it processes the results and
sends back a report. There's a main thread and whenever a request comes
in, a worker thread is spawned to handle it.

The lock is used because the thread writes the query and some statistics
to a log.

Unfortunately there is a problem with certain data that causes a null
pointer dereference. This happens maybe once a day in practise. Having
one bad line per day in the log is really not a significant problem, but
having the whole query server go down *is* really bad.

There must be many similar situations where garbage collection is exactly
what's needed.

If you think that garbage collection is exactly what is needed to
handle locking then you are mistaken.

Why do you think that Java, C#, VB.NET, etc. have threading and
locking APIs? The answer is that even though these are garbage
collected languages you still need threads and semaphores and other
protection concepts in SMP and NUMA programming styles.

 

[Tech07]

You forgot the word "Yet" at the start of the subject line of your post.

(yawn)

 

[Phil Carmody]

Unfortunately there is a problem with certain data that causes a null
pointer dereference. This happens maybe once a day in practise. Having
one bad line per day in the log is really not a significant problem, but
having the whole query server go down *is* really bad.

There must be many similar situations where garbage collection is exactly
what's needed.

Fixing your null pointer dereference is exactly what's needed.

Having the whole query server go down would perhaps have persuaded
you to fix the code earlier rather than later.

Phil, whose job next week is to kill (OK, do_exit() probably) tasks
that even *think* of misbehaving.

 

[James Dow Allen]

[... automatic mutex release on behalf of "a crashed thread" ...]

... Magically unlocking
the mutex is equivalent to pretending that the victim thread didn't
need the mutex in the first place;...

While I don't really disagree with anything Eric wrote (and am
slightly bemused that seg-faulting "only" once per day is the new
standard for software robustness), I'm afraid Eric and OP may
have different perspectives. Eric uses "magically" above with
negative connotations, I think, while *Magic* may be *just* what OP
is looking for.

How about this metaphor: when someone's struggling in the ocean,
about to go down for the 3rd time, throw him a life-preserver
for heaven's sake! Don't worry that it's a cutrate non-ISO approved
preserver!

As usual, I think I'm going to be in the minority.
James

 

[Seebs]

How about this metaphor: when someone's struggling in the ocean,
about to go down for the 3rd time, throw him a life-preserver
for heaven's sake! Don't worry that it's a cutrate non-ISO approved
preserver!

True, but the solution to "we keep throwing our kid out of the back of our
boat, and he can't swim" is not "let's have a Federal mandate that all lake
boats must have a dozen life preservers attached to them by ropes, drifting
in the water."

If he were looking for a quick hack to fix his problem, sure, that
might be the right thing for now. But proposing that substantial chunks
of stuff be changed to accommodate an unfixed problem, not so much.

-s

 

[Richard Bos]

How about this metaphor: when someone's struggling in the ocean,
about to go down for the 3rd time, throw him a life-preserver
for heaven's sake! Don't worry that it's a cutrate non-ISO approved
preserver!

Myeah. But what if he throws it back, insisting that he wants one made
of oak instead of balsa?

Richard

 

[Phil Carmody]

Myeah. But what if he throws it back, insisting that he wants one made
of oak instead of balsa?

Throw him one made of lignum vitae then, that's even sturdier.

Phil

 

[user923005]

Throw him one made of lignum vitae then, that's even sturdier.

Let's go right to one made out of a cubic foot of Osmium.
We won't accept any complaints until he can throw it back to us.