使用 glib 的哈希表的行为

发布于 2024-11-11 17:46:50 字数 837 浏览 10 评论 0原文

我想更新每个@IP 的卷。例如，每 5 秒后，我添加每个 @IP(i) 的 V(i)。好的，现在哈希表工作正常，每 T 秒更新一次。但问题是，一段时间后我发现有时同一个ip地址会在哈希表中重复两次甚至很多次。因此，当我关闭进程时，我发现相同的@IP重复了太多次。就好像哈希表或者类似的东西有问题。

这是代码这个函数“update_hashTable()”非常重要，每 X 秒调用一次我怀疑实际上是内存泄漏......因为我总是调用 malloc IP@。但它一直在工作......有什么想法吗？？？

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);
}

原文

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);
}

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

残花月 2024-11-18 17:46:50

事实上，您似乎存在内存泄漏，但这不是您的问题。问题在于 if 语句的真实路径只是重新插入与同一键关联的第二个值，这不是您想要的。

这种检查是否存在和增量算法的典型模式通常类似于以下内容。

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 */;

重要的是，一旦您拥有指向与某个键关联的值的指针，您就可以直接修改它。

如果此代码将由多个线程并行执行，则整个块应该由互斥锁保护，也许使用 GMutex：http://developer.gnome.org/glib/2.28/glib-Threads.html

gcc 提供原子内置内在函数，例如原子递增值，请参阅 http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html

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

回复收藏 0 原文

~没有更多了~