I want to update the Volume to each #IP. So that for example after each 5 s I add V(i) of each #IP(i). Ok Now the hash table works fine it keeps updated after every T seconds. But the problem is that after a certain period I find that sometimes the same ip adress is repeated twice or even a lot of times within the hash table. So that when I close the process I find the same #IP repeated too many times. It is like there is a problem with the hash table or something like that.
Here is the code this funcion "update_hashTable()" is so important it is called every X seconds I suspect in fact a memory leak ... because I always call malloc for IP#.
but it keeps working ... any idea ???
int update_hashTable( ... ) {
u_int32_t *a;
... //declarations
struct pf_addr *as;
as = ks->addr[0];
a = (u_int32_t*)malloc(sizeof(u_int32_t));
*a = ntohl(as->addr32[0]);
sz = value; // no matter it is... an int for example
if (ReturnValue=(u_int32_t)g_hash_table_lookup(hashtable, a)) {
ReturnValue +=sz;
g_hash_table_insert(hashtable, (gpointer)a, gpointer)ReturnValue);
}
else {
g_hash_table_insert(hashtable, (gpointer)a, (gpointer)sz);
}
Indeed, you appear to have a memory leak, but this isn't your problem. The problem is that the true-path of your if statement simply reinserts a second value associated with the same key, which is not what you want.
The typical pattern for this check-if-exists and increment algorithm is usually something like
gpointer val = g_hash_table_lookup(hash_table, key);
if (val == NULL) {
val = g_malloc0(...);
g_hash_table_insert(hash_table, key, val);
}
*val = /* something */;
The important thing to take away from this is that once you have a pointer to the value associated with some key, you can simply modify it directly.
If this code will be executed by multiple threads in parallel, then the entire block should be protected by a mutex, perhaps with GMutex: http://developer.gnome.org/glib/2.28/glib-Threads.html
gcc provides atomic builtin intrinsics, say for atomically incrementing the value, see http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html
Related
Lets say I have a function named loop(). In this loop() I increment a counter count.
I have few functions, A(), B(), C(), etc.
I want to call each one of these functions when the counter reaches some value (different for every function).
My current code looks like:
static unsigned int count = 0;
void loop(){
if (count == VALUE_ONE)
A();
if (count == VALUE_TWO)
B();
if (count == VALUE_THREE)
C();
..... //more cases
if (count == MAX_VAL)
count = 0;
else
count++;
}
VALUE_* are #defines so they are not being changed during the program.
Right now I am using regular if statements to check the counter value. But I want to avoid using the if statement to avoid branch mispredictions.
Is there a better way to do this? Something that will actually avoid branch mispredictions etc?
Edit:
The goal here is to optimize this part of code in order to make it in faster, as for now it sometimes doesn't finish until the time it should. I am aware that there might be a problem with function A(), B(), etc, but for now I am asking about this specific case.
To make it clear, VALUE_ONE, VALUE_TWO, VALUE_THREE, etc might be very large values and not increasing by 1. For example it might be:
#define VALUE_ONE 20
#define VALUE_TWO 1500
#define VALUE_THREE 99777
My compiler version is: gcc (GCC) 4.4.7
Why in the world are you worried about branch misprediction? Do you have a working program? Does it run too slowly? Have you narrowed the problem to branch misprediction in the code you present? Unless the answer to each of those questions is "yes", you are engaging in premature optimization.
Moreover, the conditional branches in the code you present appear to be highly predictable, at least if the counter is expected routinely to reach values in the tens or hundreds of thousands or more, as the updated example code seems to indicate. A misprediction rate on the order of 0.00001 or less -- which is about what you could expect -- will not have a measurable performance impact. Indeed, handling code such as you've presented is the bread and butter of branch prediction. You could hardly ask for a case more friendly to a branch-prediction unit.
In any event, since you are concerned about branch misprediction, your question must be not so much about avoiding the if statements in particular, but about avoiding conditional logic in general. As such, a switch construct probably is not better, at least not for the situation you describe, wherein you want to call functions only for a handful of the large number of distinct values the function will see, sprinkled across a wide range. Although the compiler could, in principle, implement such a switch via a jump table, it is unlikely to do so in your case because of how large the needed table would be, and how few of the elements would differ from the one for the default case.
A hash table has also been discussed, but that's no better, because then either you need conditional logic to distinguish between cache hits and cache misses, or else your hash table must for every input provide a function (pointer) to be called. Calling a function on every iteration would be far more costly than what you are doing now.
Additionally, you need a perfect hash function to avoid conditional logic in the HT implementation. If the possible values of your counter are bounded by a small enough number that a hash table / perfect hash could be used to avoid conditional logic, then a plain array of function pointers would be lighter-weight than a hash table, and could serve the same purpose. It would still have the same problem with function-call overhead, however. If you insist on avoiding conditional logic then this would probably be the best way to go for your particular problem. But don't.
Leave optimisations to the compiler in the first place. Concentrate on writing human-readable code. Optimise only iff you have a timing problem and after you profiled the code. Then concentrate on the hot-spots. If some code is good for branch-prediction is hard to predict with modern CPUs.
Use a switch (for an easier to read introduction please check a good C book) statement to make the code better readable:
switch ( count ) {
case VALUE_ONE:
f1();
break;
case VALUE_TWO:
f2();
break;
...
default:
// be aware to catch illegal/forgotten values, unless you
// are absolutely sure they can be ignored safely.
// still having a default label is good style to signal "I
// though about it".
break;
}
That is not only the most readable version, but also gives the compiler the best chance to optimize the code.
If the values are just increasing by 1 (1, 2, 3, ...), modern compilers will automatically generate a jump-table, even for partial successions (1, 2, 3, 7, 8, etc.), so that is as fast as a manually created function-table. If they are not, it still often will generate something like if ... else if ... else if ... constructs.
Note the case-labels must be constant-expressions.
Edit: After you clarified the values may not be adcascent, my answer still holds true. Depending on the number of compare-values, the switch still is the best solution unless prooved wrong. Try this first, profile and only optimise iff necessary. A hash-table might not be worth the effort.
Even if you'd use a hash-function, the switch above will come in handy. Just use the hash-value instead of count.
I'm skeptical whether the original function is a bottleneck or an effective place to be optimizing. But hey, I like puzzles...
Given that the count is incrementing and the match values are increasing, you really only need to test against the upcoming match value. And while you can't use your match values as an array index you could create states that can be used as an array index. Try something like this.
static unsigned int count = 0;
typedef enum
{
WAITING_FOR_VALUE_ONE = 0,
WAITING_FOR_VALUE_TWO,
WAITING_FOR_VALUE_THREE,
...,
WAITING_FOR_MAX_VALUE,
MAX_STATES
} MyStates;
static MyStates state = WAITING_FOR_VALUE_ONE;
void waitForValueOne()
{
if (count == VALUE_ONE)
{
A();
state++;
}
}
void waitForValueTwo()
{
if (count == VALUE_TWO)
{
B();
state++;
}
}
void waitForMaxValue()
{
if (count == MAX_VAL)
{
count = 0;
state = 0;
}
}
void (*stateHandlers[MAX_STATES]) () =
{
waitForValueOne,
waitForValueTwo,
waitForValueThree,
...
waitForMaxValue
}
void loop()
{
(*stateHandlers[state])();
count++;
}
After count reaches MAX_VAL, your original implementation will run the next loop with count = 0 whereas my implementation will run the next loop with count = 1. But I'm sure you can fix that if it's important.
Update:
I don't like how loop called the state handler every count. It really only needs to call the state handler when there is a match. And also the comparison doesn't need to be repeated in every state handler function if it's performed in loop. Here are a few edits that implement this improvement.
static MyStates state = WAITING_FOR_VALUE_ONE;
static unsigned int matchValue = VALUE_ONE;
void waitForValueOne()
{
A();
state++;
matchValue = VALUE_TWO;
}
void waitForValueTwo()
{
B();
state++;
matchValue = VALUE_THREE;
}
void waitForMaxValue()
{
count = 0;
state = 0;
matchValue = VALUE_ONE;
}
void loop()
{
if (count == matchValue)
{
(*stateHandlers[state])();
}
count++;
}
In your case I can't see any reason for an optimiziation.
But in the case your interrupt will be fired every 20µs and your handler consumes 50% of the complete cpu time, as you check aginst 200 values, then and only then you could change your code.
For an incrementing counter, you only need a single if as you always know which value will be the next one.
void isr(void)
{
count++;
if (count == nextValue)
{
if ( count == VALUE_ONE )
{
A();
nextValue=VALUE_TWO;
}
else if ( count == VALUE_TWO )
{
B();
nextValue=VALUE_THREE;
}
...
}
}
In 99% of the time, the ISR() only needs to increment the counter and check that the value isn't reached.
In reallity, I would use an array of actions and times, instead of the if else if block.
This seems like it should be simple but I wasn't able to find much related to it. I have structure which has different fields used to store data about the program operation. I want to log that data so that I can analyse it later. Attempting to continuously log data over the course of the programs operation eats up a lot of resources. Thus I would only like to call the logging function when the data has changed. I would love it if there was an efficient way to check whether the structure members have updated. Currently I am playing a shell game with 3 structures (old, current, and new) in order to detect when the data has changed. Thanks in advance.
You may track structures and its hashes in your log function.
Let you have a hash function:
int hash(void* ptr, size_t size);
Let you have a mapping from pointer to struct to struct's hash like:
/* Stores hash value for ptr*/
void ptr2hash_update_hash(void* ptr, int hash);
/* Remove ptr from mapping */
void ptr2hash_remove(void* ptr);
/* Returns 0 if ptr was not stored, or stored has otherwise*/
int ptr2hash_get_hash(void* ptr);
Then you may check if your object was changed between log calls like this:
int new_hash = hash(ptr, sizeof(TheStruct));
int old_hash = ptr2hash_get_hash(ptr);
if (old_hash == new_hash)
return;
ptr2hash_update_hash(ptr, new_hash);
/* Then do the logging */
Don't forget to remove ptr from mapping when you do free(ptr) :)
Here is simple hash table implementation, you will need it to implement ptr2hash mapping.
Simple hash functions are here.
If you're running on Linux (x86 or x86_64) then another possible approach is the following:
Install a segment descriptor for a non-writable segment in the local descriptor table using the modify_ldt system call. Place your data inside this segment (or install the segment such that your data structure is within it).
Upon write access, your process will receive a SIGSEGV (segmentation fault). Install a handler using sigaction to catch segmentation faults. Within that handler, first check that the fault occurred inside the previously set segment (si_addr member of the siginfo_t) and if so prepare to record a notification. Now, change the segment descriptor such that the segment becomes writable and return from the signal handler.
The write will now be performed, but you need a way to change the segment to be non-writable again and to actually check what was written and if your data actually changed.
A possible approach could be to send oneself (or a "delay" process and then back to the main process) another signal (SIGUSR1 for example), and doing the above in the handler for this signal.
Is this portable? No.
Is this relyable? No.
Is this easy to implement? No.
So if you can, and I really hope you do, use a interface like already suggested.
The easiest way what you can try is, You can just keep two structure pointers. Once you are receiving the new updated values that time you can just compare the new structure pointer with the old structure pointer, and if any difference is there you can detect it and then you can update to old structure pointer so that you can detect further changes in updated value in future.
typedef struct testStruct
{
int x;
float y;
}TESTSTRUCT;
TESTSTRUCT* getUpdatedValue()
{
TESTSTRUCT *ptr;
ptr->x = 5;
ptr->y = 6;
//You can put your code to update the value.
return ptr;
}
void updateTheChange(TESTSTRUCT* oldObj,TESTSTRUCT* newObj)
{
cout << "Change Detected\n";
oldObj = newObj;
}
int main()
{
TESTSTRUCT *oldObj = NULL;
TESTSTRUCT *newObj = NULL;
newObj = getUpdatedValue();
//each time a value is updated compae with the old structure
if(newObj == oldObj)
{
cout << "Same" << endl;
}
else
{
updateTheChange(oldObj,newObj);
}
return 0;
}
I am not sure, it gives you your exact answer or not.
Hope this Helps.
I have a program that enables multiple threads to insert entries into a hashtable and retrieve them. The hashtable itself is a very simple implementation with a struct defining each bucket entry and a table (array) to hold each bucket. I'm very to new to concurrency and multithreading, but I think that in order to avoid data from being lost in the table during insert and read operations, some kind of synchronization (in the form of something like mutex locking) needs to be added to avoid preemption on one process's data operation by another's.
In practice though, I'm not really sure how to tell where a process could be preempted in either a data read or write operation on the hashtable and where exactly locks should be placed to avoid such problems as well as dead locks. As per this website, for the hashtable insert method, I added a mutex lock before each key gets inserted into the table and unlock it at the end of the function. I essentially do something similar in the function where I'm reading data from the hash table and when I run the code, it seems that the keys are successfully being inserted initially, but the program hangs when the keys are supposed to be retrieved. Here is how I implemented the locking for each function:
// Inserts a key-value pair into the table
void insert(int key, int val) {
pthread_mutex_lock(&lock);
int i = key % NUM_BUCKETS;
bucket_entry *e = (bucket_entry *) malloc(sizeof(bucket_entry));
if (!e) panic("No memory to allocate bucket!");
e->next = table[i];
e->key = key;
e->val = val;
table[i] = e;
pthread_mutex_unlock(&lock);
pthread_exit(NULL);
}
// Retrieves an entry from the hash table by key
// Returns NULL if the key isn't found in the table
bucket_entry * retrieve(int key) {
pthread_mutex_lock(&lock);
bucket_entry *b;
for (b = table[key % NUM_BUCKETS]; b != NULL; b = b->next) {
if (b->key == key) return b;
}
pthread_mutex_unlock(&lock);
pthread_exit(NULL);
return NULL;
}
So the main problems here are:
How to tell where data is being lost between each thread operation
What could cause the program to hang when the keys are being retrieved from the hashtable?
First, you should read more about pthreads. Read also pthreads(7). Notice in particular that every locking call like pthread_mutex_lock should always be later followed by a call to pthread_mutex_unlock on the same mutex (and conventionally you should adopt the discipline that each lock and unlock happens in the same block). Hence your return in the for loop of your retrieve is wrong, you should code:
bucket_entry *
retrieve(int key) {
bucket_entry *res = NULL;
pthread_mutex_lock(&lock);
for (bucket_entry *b = table[key % NUM_BUCKETS];
b != NULL; b = b->next) {
if (b->key == key)
{ res = b; break; };
}
pthread_mutex_unlock(&lock);
return res;
}
Then you could use valgrind and use a recent GCC compiler (e.g. 5.2 in November 2015). Compile with all warnings & debug info (gcc -Wall -Wextra -g -pthread). Read about the sanitizer debugging options, in particular consider using -fsanitize=thread
There are few reasons to call pthread_exit (likewise, you rarely call exit in a program). When you do, the entire current thread will be terminated.
I have a requirement in C similar to function overriding. I have 2 devices with different device IDs. I have a process which just calls device_create(device_id). The process doesn't know which device_create to call. It is upto driver of the device to execute device_create if the device_id matches to driver's device Id. Is there any way to do it in C?
If you use different shared objects (or dlls) to implement the function you could handle this programatically on your own. You could create a plugin like structure and use something like the Command pattern.
Not exactly simple, but can help with your problem.
Cheers.
OK. Understand I'm still of the mark, but leave this post for now.
You do not know the ID when process starts. When HW is attached you read the ID and want to call correct function based on the ID but without using the ID directly?
The closest I can think of as a simple solution is by using an array of function pointers:
void (*funs[3])(void) = {
&device_create100,
&device_create200,
NULL
};
But then only if you can normalize the ID to match index of the array. Say all ID's are in the range 1000-1032 that would be an 32 long function pointer array where you can use ID - 1000.
As this is rather unlikely you could resort to a sorted list, binary tree, hash table or the like on which you do a lookup.
struct node {
int (*fun)(void);
int id;
struct *node left;
struct *node right;
}
This is of course then assuming you have a rather big list of possible ID's and a switch is out of the question.
Old post.
What about function pointers:
int (*device_create)(int);
int device_create_init(int id)
{
switch (id) {
case 0x0a:
device_create = &device_create_100;
break;
case 0x0b:
device_create = &device_create_200;
break;
}
/* After first call, the now set device_create_xxx function will be
invoked on device_create() */
return device_create(id);
}
int main(void)
{
device_create = &device_create_init;
/* Loop */
return 0;
}
I am understanding and implementing the concept of threading in my application. Since now things are going good. But I have few questions still unanswered and they are making me slow now. I would appreciate if anyone replies to even any of them
In Createthread(), can we only take 1 argument? as I have seen in MSDN website and all other examples that I have seen I saw only 1 argument, LPVOID.
The other thing is , what does the return value DWORD WINAPI means as a return value? Can we have only DWORD , int or any other return type. I suppose it has something to do with HANDLE (may be)
I want to use the array of the thread, hence I learn the array to functions, and (as I have understood) threads are itself just a function called by CreateThread() routine, hence I tried to implement that concept there but could not because of the return type DWORD WINAPI was not allowing me to do so?
I have one single thread for saving files, now I want its array so that I can save multiple files at the same time (not exaclty the same starting time, but sort of parallel file saving). How can I do that?
Thanks
Shan
Indeed, you can only take one argument, of type void * (LPVOID).
However, since it can point to anything, it can point to a struct
or object (usually allocated on the heap for lifetime reasons).
WINAPI is not part of the return value, it's the function's calling
convention. The function must return a DWORD or anything that fit
in it. It must NOT return a pointer, because a pointer can't fit a
DWORD in Win64.
I don't understand, please elaborate what you're
trying to do.
Usually for this you need a single thread function,
passed several times to CreateThread() with a different argument
each time. Don't forget to keep the thread handles (which you'll
likely save in an array) until you stop needing them and close them
with CloseHandle().
for the point number three I guess I understood and will try differently. I was using
DWORD WINAPI save_uwpi_file0( LPVOID )
{
while(1)
{
if(release == 1 && flag_oper1 == 1)
{
int w_cnt = 0; FILE *opfile;
char fname[30] = "txt_file0.txt";
//opening file for write
opfile = fopen(fname , "w");
printf("assigning memory for file 1 \n");
ssint *Lmem = (ssint *)malloc( sizeof(ssint)*size_of_memory);
memcpy(Lmem, pInDMA, sizeof(ssint)*size_of_memory);
release = 0;
printf("relseaing for second file saving\n");
for( int nbr = 0; nbr < size_of_memory; nbr++){
fprintf(opfile , "%hi\n", Lmem[nbr] );
}
printf("aligned free 1\n");
free(Lmem);
fclose(opfile);
printf("File saved 1\n\n");
return 1;
} //if statement ends
}
}
and I was using following to make the pointer to (thread) function
DWORD WINAPI (* save_uwpi_file0)(LPVOID);
I guess I should try something like
DWORD (* save_uwpi_file0)(LPVOID);
I will do it and post the result here