comp.programming.threads Google Group

Re: properly shutdown threads

steve.removet...@watt.com (Steve Watt) — Sat, 19 Jul 2008 17:49:28 UT

In article <6edji5F6gra...@mid.uni-berlin .de>,
[ removed good advice to look at other art ]
Actually, any implementation these days that doesn't correctly unwind
the stack on cancellation could easily be called "hopelessly broken".
Note that pthread cleanup handlers require an unwind-like activity,
though some implementations did odd things like separate linked lists.

Re: false sharing confusion!!

x...@xxx.xxx (Chris Thomasson) — Sat, 19 Jul 2008 13:46:46 UT

Agreed.
Indeed! If the objects are "read-mostly", then it could be beneficial
to pack several of them in a single L2 cache-line which would aid certain
cache-blocking techniques and allow an initial cache-line load to bring
in several objects at once; that's good. On the other hand, if the objects
are "write-mostly", then keeping a single object per-cache-line tends to

Re: false sharing confusion!!

dav...@webmaster.com (David Schwartz) — Sat, 19 Jul 2008 10:24:48 UT

That's a "bug" in that specific implementation. I put "bug" in quotes
because it's a trade-off, but one that I think was made very badly.
Keeping critical sections small saves memory when you have a lot of
them and can improve performance if multiple "nearby" critical
sections are used by the same thread many times (less memory

Re: Condvar Algorithm 6b by Terekhov & Thomas

x...@xxx.xxx (Chris Thomasson) — Sat, 19 Jul 2008 09:54:33 UT

[...]
There is an updated version; algorithm 8a:
[link]

Re: pthread_mutex_lock / unlock affecting compiler optimization and/or caching ??

x...@xxx.xxx (Chris Thomasson) — Sat, 19 Jul 2008 09:47:20 UT

It certainly could be! If the `pthread_mutex_t' data-structures are not
properly
padded and aligned, well...

Re: false sharing confusion!!

x...@xxx.xxx (Chris Thomasson) — Sat, 19 Jul 2008 09:44:38 UT

Sadly, this does not avoid the possibility of false-sharing wrt an
applications
shared-data. Also, keep this in mind:
[link]
[link]
There is false-sharing among CRITICAL_SECTIONS and the data they protect,

Re: false sharing confusion!!

x...@xxx.xxx (Chris Thomasson) — Sat, 19 Jul 2008 09:40:16 UT

Word-tearing aside for a moment, I have not seen any bugs caused by
false-sharing, but it does simply destroy performance by constantly
invalidating cached data.
[link]
If you want to avoid false-sharing you really need to find out the L2

hotsexy pictures

sexyjeni...@gmail.com (sexy) — Sat, 19 Jul 2008 08:36:23 UT

hotsexy pictures
spicy sexy pictures
animalsex pictures
******************************
[link]
****************************** *

Re: false sharing confusion!!

dav...@webmaster.com (David Schwartz) — Sat, 19 Jul 2008 08:00:14 UT

You're trying to solve a problem you don't have.
Generally, you can avoid false sharing with three simple rules:
1) Don't try to write your own low-level primitives. Use ones that
have been developed and optimized by experts for your platform.
2) Don't share sub-objects. If you need to share something between

Re: properly shutdown threads

dooms...@knuut.de (Ulrich Eckhardt) — Sat, 19 Jul 2008 07:31:14 UT

Does a file get destroyed when the file-class instance is destroyed?
Seriously, both a file class and a thread class ARE not the according thing
but they represent a HANDLE TO the thing. That means that you can't
hardcode the way to shut down a thread from the baseclass. The way to do
that strongly depends on the work the actual thread is doing, sometimes a

Re: pthread_cond_signal - race condition

dav...@webmaster.com (David Schwartz) — Fri, 18 Jul 2008 23:35:14 UT

If the thread goes to run another task, *that* task is not done. The
task it finished is still done.
Or you can set a timer for each task. It depends on how your code is
structured. Ideally, you would already have some kind of sensible
timer infrastructure. But if not, you can fake it with a scan.
Okay. The list of tasks is global.

false sharing confusion!!

mynickmyn...@yahoo.com (mynickmynick) — Fri, 18 Jul 2008 17:35:21 UT

I know very badly the problem of false sharing.
Questions:
(1) There is a false sharing of 2 processors with 2 cache which can
lead ONLY to inefficiency BUT NOT to bugs (unwanted rush conditions on
not really shared adjacent data)?
(2) There is a false sharing of core-2 Intels with two cores but one

Re: pthread_cond_signal - race condition

h.b.furus...@usit.uio.no (Hallvard B Furuseth) — Fri, 18 Jul 2008 15:31:35 UT

You mean the Manager thread, rather than Manager module?
Once a worker thread is done with its task and wants to tell that to the
manager thread, even if just by calling pthread_exit(), it is no more
likely than the manager thread to do any more I/O. Unless your or the
task's code has a bug:
- if the task has overwritten its caller's stack or data structures.

cheap AP watch PayPal

yuwenwu...@gmail.com — Fri, 18 Jul 2008 14:43:50 UT

cheap AP watch PayPal
Dear friend
Welcome to shopping on [link]
Our company launched a new activity which will largely save your time.
If you pay us more money , we
will give you the equal web money which you can use in next order, so
you need not go to the bank to
remit the money every time. Also, we can send your parcel at the first

pthread_join(any) (Re: pthread_cond_signal - race condition)

d...@furrfu.invalid (Drew Lawson) — Fri, 18 Jul 2008 14:01:40 UT

In article <hbf.20080717f...@bombur.uio.n o>
I've just recently been dipping my toes into pthreads, and I've
been wondering about that.
Since pthreads are pretty well thought out, I assume that there are
good reasons for not having that function, but the reasons why it
would be a Bad Thing don't seem obvious to me.