|
After creating a pthread, i am setting the thread id to a custom id using a map.
pthread_t threads[noOfThreads];
struct thread_data td[noOfThreads];
thread= pthread_create(&threads[i], NULL, startFunc, (void *)&td[i]);
setID(threads[i], td[i].thread_id);
SetID function
setID(pthread_t pid, int id ){
thread_ids[pid]=id;
definition of map
std::map<pthread_t, int> thread_ids;
I want to get the mapped value based on the key value in the following function but dont know how to do exactly.
getID function
getID() {
if (thread_ids.find(pid) ==thread_ids.end()) return -1;
return thread_ids[pid];
}
I am very beginner so spare me if i am making a stupid mistake and please point that and help me correcting it
c++, pthread
modified 13-Jul-18 12:04pm.
|
|
|
|
|
Why are you using a struct for a simple value, i.e. int? And why do you need to map the real thread id to some other value? It is not really clear what you are trying to do.
|
|
|
|
|
I am planning to have more variable in the struct e.g.
struct thread_data {
int thread_id;
const char *message;
double result
};
Richard MacCutchan wrote: And why do you need to map the real thread id to some other value?
The application in which i am creating pthreads is a simulation environment on top of which my actual thread scheduling library will execute so the each pthread act like virtual core. Each core(pthread) has its own work package queue from which it retrieves the package for execution and when it is empty it attempts to steal from other cores(via work stealing method). Every core has a package manager singleton class which is responsible for adding and getting the package from the queue. In order to access the other cores(using the singleton class) i need the mapping so that whenever each core access the package manager class (and its queue), it do based on the custom id.
I hope i explained it better this time
|
|
|
|
|
Quote: whenever each core access the package manager class (and its queue), it do based on the custom id.
Why not the real id?
|
|
|
|
|
Hi all,
Tt's a HTML Input box like this.
<input id="testInput" name="testInput" value="" tabindex="0" />
and for some reason, I cannot use ASP.net textbox.
However, I need to disable it when a button is clicked (I tried both AUTOPOSTBACK and non-AUTOPOSTBACK button) .
I tried the followings in c# but none of these works.
Page.ClientScript.RegisterStartupScript(this.GetType(), "clientscript", "document.getElementById('testInput').readOnly = true;");
Page.ClientScript.RegisterStartupScript(this.GetType(), "clientscript", "document.getElementById('testInput').disable= true;");
Page.ClientScript.RegisterStartupScript(this.GetType(), "clientscript", "document.getElementById('testInput').disable= 'true';");'
Please advice, thanks!
|
|
|
|
|
|
Would you ever do something like this:
std :: map<double, MyType, std :: less<double> >
I don't see a reason why not to do it, but I have a bad feeling doing it.
Any Remarks / objections?
Ok, this double - Key is a user Input with a known/limited number of decimal places. I could also take this into acount and use a
std :: map<int, MyType, std :: less<int> >
But why I should?
Btw: Performance is out of questions, the map size is Maximum 10 items.
Thank you very much in advance.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
In 64bit code (so using XMM registers) it'll probably work, unless any DLL secretly changes a rounding mode on you and "forgets" to set it back. In 32bit code (usually using the x87 FPU stack), who knows? The danger there as usual is that keeping a double in an FPU register keeps it at whatever value was actually computed (which depending on how stod works internally may have bits set in the part of the 64bit significand that extends beyond the 53 bits you usually get) while storing it to memory and reloading it changes the value, and this is something that compilers think is a normal part of how they work so they do it outside of your control, though you can force a store/reload to get a safer value to work with. So it may still work, but there are some sneaky conditions that may depend on specific codegen choices the compiler makes.
|
|
|
|
|
Thank you so much!
To be honest I don't get all of your explanations at the moment. But the most important Thing is, that you Point out, that there can be a Problem... and that corresponds with "my bad Feeling".
So now it will be my part to investigate more for possible pitfalls
Thank you very much again.
[Edit]
And please flag your Response as an answer, it is much more than a "general"
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Simple answer: no. Double and float values have an inherent precision problem so you can never rely on two numbers being the same. You need to rethink your design.
|
|
|
|
|
This is really too pessimistic about floating point arithmetic though. There are definitely cases where doubles will reliably have exactly equal values. They're not non-deterministic, just hard to work with and 80bit nonsense messes things up extra.
|
|
|
|
|
This is really too pessimistic
No, realistic. Far too many people use floating point numbers where they are not necessary, or actually wrong.
|
|
|
|
|
That is true, but "you can never rely on two numbers being the same" is not. There are conditions that can be satisfied that will make the numbers the same.
|
|
|
|
|
Yes, but you understand floating point representation. Too many developers do not appear to share that understanding.
|
|
|
|
|
So with your Argumentation one Need also to say: Don't use int_64 ... which of course makes no sense.
A double value has a discret number of numbers it can represent, same as an int_64 has 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
No, that is not what I am saying at all. And it appears, that like so many people on these forums, you also do not understand how floating point numbers work.
|
|
|
|
|
Try this
#define NUMBER 133333333
int main()
{
int nValue = NUMBER;
float fValue = NUMBER;
printf("%d\n", nValue);
printf("%f\n", fValue);
|
|
|
|
|
Thank you very much for this. I'm completely aware of such effects and also on the normalizing stuff.
Thank you again 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Quote: Is my idea too dirty?
I have just the same feeling about.
|
|
|
|
|
I'm a bit late to the party.
The key point of a map is that no two elements in a map container can have equivalent keys. If the number of significant digits entered is less than the precision of double values, this will not happen (besides entering the same value again which applies to ints as well).
But you might get problems when trying to access elements by key when the argument is from other sources (affected by rounding).
That would be my bad feeling:
While there is no problem with the map itself, key based operations ([]operator, erase, swap, find) might behave not as expected (no match). Even when not using such operations now but only iterator based ones, they may be used later when updating the code. So you should at least place a comment about this.
Another option is creating your own std::map based class that disables the affected operations or replaces them with a version that treats close numbers as identical (defining an epsilon).
|
|
|
|
|
Thank you very much for your comments and your time.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
0x01AA wrote: std :: map<double, MyType, std :: less<double> >
Hi,
I was avoiding this discussion but I wanted to just add one more comment. The FPU has a state that has an affect on the precision. In other words... when the FPU is in various states you get a different rounding value. You can control this state with _controlfp_s
Printer DLL and other libraries outside of your control could potentially change the thread FPU state causing your std::map to contain multiple floating point numbers from the same calculations. Unfortunately on Windows user-applications cannot always control third-party DLL from loading into your process. Those DLL could modify and then fail to reset the floating point state.
The answer is "Yes" what you are proposing would work 99% of the time or in "laboratory" conditions where you control both the hardware and software. But if you tried to ship out a commercial product using the above technique... you will almost certainly have a small percentage of the conditions I described above.
Best Wishes,
-David Delaune
|
|
|
|
|
Wow, great that you share this knowledge.
Thank you very much for this.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Hi,
I need basics to know about COM/DCOM. Any good article, please point me the link
Thanks,
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
