|
I start a native thread in my Thread constructor too, so maybe I'm not wise either! I need to think about your suggestion. Which is, if I understand correctly, to create the Thread object first and then invoke a Thread::run function to actually create the native thread. That sounds appealing, even though I dislike two-phase construction. There would also be a window in which the native thread could start to run before its handle got written into the Thread object. You'd think that window would be very tiny, but given how vigorously Windows and Linux context switch, I'd want to close it.
|
|
|
|
|
I was thinking more that the user of Thread object invokes the Thread::start function when the thread is needed. This is a nice way of passing the buck to the user if he started the thread at an inappropriate time
If you want to take a look at my complicated way of starting threads you can see it here mlib/thread.cpp - neacsum/mlib[^] (it's Windows only).
The steps are:
1. Creator makes new thread with static function as entry point. Passes *this as argument.
2. New thread starts suspended to avoid any race conditions (existed in older Windows versions - haven't checked in Win10).
3. Creator resumes suspended thread and waits for a "created" event.
4. New thread signals the created event and waits for the "started" event.
5. Code in creator thread invokes thread::start() function. This one signals the "created"event and new thread runs.
If you want to see it in action, you can take a look at the code it this article: Producer/Consumer Queues in C++[^]
Mircea
|
|
|
|
|
My approach is similar but has no concept of creating a thread until it needs to run, so start would always be invoked immediately. Almost all the threads are daemons.
|
|
|
|
|
Greg Utas wrote: I use the pthread_t from pthread_self as a key into a std::map, and having to replace that with a string is gross I didn't notice this before. A GUID is the same width as a 128-bit integral type. You don't need to use a std::string as your key.
Check to see if your compiler supports std::map<__int128>
|
|
|
|
|
The signatures for these are
extern int pthread_getname_np(pthread_t __target_thread, char *__buf, size_t __buflen);
extern int pthread_setname_np(pthread_t __target_thread, const char *__name); No GUIDs, unfortunately.
EDIT: I did manage to fix the problem without much difficulty, so things are progressing. But soon I'll be testing stuff that relies on -fnon-call-exceptions, which could lead to the whole thing getting binned. 🤞
|
|
|
|
|
You will be amused to learn that I'm hoping to run all threads at the same priority. I think it will work, with only a minor drawback. The current design is overly defensive given how vigorously both Windows and Linux context switch and has largely become a case of "it's always been done that way."
|
|
|
|
|
Greg Utas wrote: You will be amused to learn that I'm hoping to run all threads at the same priority. Yes I know, I've been spying paying attention to your latest endeavors.
It crossed my mind that you could use pthread_setname_np() to name your threads Randor so that you can have the satisfaction of terminating me while you write your Linux libraries.
|
|
|
|
|
Terminating a foil and source of useful info would be foolish.
|
|
|
|
|
Any reason you can't use std::thread ?
Paul Sanders.
Not that the story need be long, but it will take a long while to make it short - Henry David Thoreau
Some of my best work is in the undo buffer.
|
|
|
|
|
I thought about wrapping a std::thread but chose not to for the reasons outlined here[^].
|
|
|
|
|
Sorry, I missed that.
In that case, it would be simple enough to wrap pthread in a little class of your own. I wouldn't bother with an external library personally, especially if you don't trust it anymore. I do in fact do this myself (because my code also dates back to pre-C 11 days) and it was very little work.
Paul Sanders.
Not that the story need be long, but it will take a long while to make it short - Henry David Thoreau
Some of my best work is in the undo buffer.
|
|
|
|
|
Wrapping pthread is indeed what I did when porting to Linux. It's wrapped by this[^], for which the Linux target is here[^]. And that, in turn, is wrapped by a much more comprehensive Thread [^] class.
|
|
|
|
|
Nice wrapper.
I re-read your original post, and I now understand what your problem was / is - that pthread_t s get re-used more quickly than you would like. Kinda dangerous to assume that they won't be...
Paul Sanders.
Not that the story need be long, but it will take a long while to make it short - Henry David Thoreau
Some of my best work is in the undo buffer.
|
|
|
|
|
|
My approach to gambling is pretty simple: look at the cars.
What car does the average casino owner / lottery CEO / bookmaker drive? What did that probably cost? Call it "x"
What car does the average punter drive? What did that cost? Call that "y".
Invariably, x > y (and normally x >>>>> y) - so the punter is funding the owner / CEO / bookie and is almost certain to lose ...
I'm just not a gambler - I last played a fruit machine back in the early eighties, when I won a £50 jackpot which paid off my whole overdraft! I realized that statistically I'd never do that again, so putting money in them was pointless.* #
* I spent it all on beer instead.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yup. Back in the day, I worked many conventions in (among other places) Vegas. Mostly in the big hotels, MGM etc. Great place for food and entertainment as long as you stay out of the casino. Always did. Great idea to check out the lifestyle of the owners.
If you can't contain your urge to gamble, go to the old section of town where you can learn with nickles and dimes. Well you could some 20 years ago.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
It doesn't really matter whether you gamble with small or large amounts. The key rule is never gamble what you cannot afford to lose. Oh, and never, ever, chase your losses.
|
|
|
|
|
Exactly the same goes with investments in the bourse / stock market
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Well it is just a form of betting.
|
|
|
|
|
True...
and sometimes is even worse than gambling.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
If there's no fundamental reason for a stock getting cheaper, like bad news or being overvalued, adding to a position can make sense. It's on sale! How long it will take to recover is the question. Maybe someone had to sell and it will come back quickly. Maybe the sector lost some of its appeal and it will take longer. Or maybe there's bad news that you don't know about yet.
|
|
|
|
|
Greg Utas wrote: Maybe the sector lost some of its appeal and it will take longer. Or maybe there's bad news that you don't know about yet.
I assume the name "JDS Uniphase" rings some bells to you
Mircea
|
|
|
|
|
JDSU did ring a bell. I was also at Nortel for over 20 years.
|
|
|
|
|
|
When I was in the Navy, I saw sailors lose a whole month's wages on the turn of one card.
That's where I learned gambling was a fool's game. I have never gambled, since.
Money is too hard to come by, to throw it away like that.
ed
|
|
|
|