问题标签 [contention]

我正在尝试修改 mac-802.11.h 文件中的 cw_ 值，但没有成功。

通常是这样完成的，cw_=(cw_<<1)+1.

这是我试过的，cw_=(cw_ * 1.8)+1.

以上对于模拟后的平均吞吐量和平均丢弃的数据包的结果没有变化。

我错过了什么吗？还是只能以二进制方式修改CW值。

我在 500x500 的环境中使用 10 个节点。TCL 中使用了一个 TCP 代理和 FTP 应用程序。节点随机移动，而 TCP 代理和接收器在模拟中连接到它们各自的节点。

Peterson 的 2 进程算法的无争用复杂度为 4（在入口代码中执行 3 两次对共享寄存器内存的访问，在退出代码中执行一次）。如何修改 Peterson 的 2 进程算法，使其无争用复杂度为 3？谢谢。

System V有三种ipc方式：MessageQueue、SharedMemory、Semaphore。当两个进程同时对其进行读写时，我应该使用线程锁之类的同步吗？

和 POSIX IPC？

我对 std::map 有一个奇怪的行为（或 std::set，在这种情况下它们的行为似乎相同）。 可能是我对这应该如何工作有一个严重的误解。 我正在使用 VS2010 SP1。

以这个函数为例：

现在，如果我运行 8 个线程，每个线程进行 100,000 次迭代，g_nElapsed 将大约为 40 秒。如果我以 800,000 次迭代运行 1 个线程，g_nElapsed 将约为 5 秒。我的印象是 g_nElapsed 对于任何合理数量的线程都应该大致相同。可以这么说......处理器使用率随着线程数的增加而增加，即使工作保持不变。但是，似乎与集合的某种资源争用会导致运行时间增加。但为什么？这是线程本地...

我确信这是一个简单的误解和一个简单的修复，但我不太确定问题出在哪里。

以下代码不会出现此行为：

我开始假设单核机器只能运行一个线程。现在我编写了一个基于 java/spring 的 junit 测试，它产生 20 个线程，它们使用 BigDecimal 计算大量的阶乘。

我用 Visual VM 监视了那个 junit，我可以看到所有 20 个线程都在工作，并且在 Visual VM 中显示为正在运行（绿色）。据我了解，jvm 使它们看起来好像都在运行，但在非常精细的级别上，每个线程都将轮流占用 CPU 周期。有没有一种方法或工具可以直观地或通过数字证明所有线程确实相互干扰并且 CPU 从一个线程切换到另一个线程？或者换句话说，我想查看给定数量的执行给定功能的线程，由于 CPU 的极端上下文切换，饱和点或收益递减是多少。

我需要解决的实际问题是在大型 Java 应用程序中调整线程。如果我在示例运行中看不到线程争用，那么我也将无法在大型应用程序中看到线程争用/滥用。

Summary:

I am interested in knowing what's the best practice for high throughput applications that have bulk messages trying to update the same row and get oracle deadlock errors. I know you cannot avoid those errors but how do you recover from them gracefully without getting bogged down by such deadlock errors happening over and over again.

Details:

We are building a high throughput JMS messaging application. Production environment will be two weblogic 11g nodes (running 6 MDB listener instances each). We were getting Oracle deadlock errors (ORA-00060) when we get around 1000 messages all trying to update the same row in oracle database. Java synchronization across nodes is not possible in standard java threading API (unless there's no other solution we don't want to use any 3rd party solutions like terracotta etc).

We were hoping Oracle "select for update WAIT n secs" statement will help because that will essentially make the competing threads (for the same row) wait few seconds before the first thread (who got the lock on the row first) gets done with it.

First issue with "SELECT FOR UPDATE WAIT n" is it doesn't allow using milliseconds for wait times. This starts negatively affecting our application's throughput because putting 1 sec WAIT (least wait time) causes delays on the messages.

Second thing we are fiddling with weblogic queue re-delivery delay parameter (30 secs in our case). Whenever a thread bounces back because of the deadlock error, it will wait 30 seconds before being re-tried.

In our experience 1000 competing messages, in a lot of situations take forever to get processed because the deadlock keeps on happening over and over.

I understand that with the current architecture we are supposed to get deadlock errors regardless ( in case of 1000 competing messages) but application should be resilient enough to recover from these errors after retrying the looping messages.

Any idea what we are missing here ? anybody who has dealt with similar issues before?

I am looking for some design ideas that can make this work resiliently so that it recovers from this deadlock situation and eventually processes all messages in reasonable amount of time without using much additional hardware.

COMPUTATION DETAILS: These 1000 messages will EACH create 4 objects of 4 different position types each having a quantity associated with it. These quantities will have to merged into those 4 different slots (depending on the position type). The deadlock is happening when those 4 individual slots are being updated by each individual thread. We have already ordered those individual updates in a specific order before being applied to the database rows to avoid any possible race conditions.

我正在阅读“索引争用”并找到以下解释：

Oracle b-tree 索引是“右手”的，b-tree 的右手叶包含最低树级别中的最高键。

当基于用户生成的键（即序列）插入行时会发生索引叶节点争用，并且由于序列键始终是高阶键，因此低级索引树节点的每个插入都必须向上传播到高键b-tree 索引中的指标。

oracle b-tree索引是右手的还有其他缺点吗？

索引争用/插入争用的其他原因可能是什么？

首先，我为一个冗长的请求道歉。

我有一个基础设施，其中有多个线程，每个线程都在等待它们的 WaitHandle (AutoResetEvent) 直到有活动排队。出于以下原因，我正在考虑更改该基础架构。每个线程都在自己的活动上工作。（我有一组不同的活动要管理）。

我认为当前基础架构的缺点是我拥有与线程（活动）本身的数量一样多的等待句柄，并且哪个（线程数）可以保持增加或减少。

当前逻辑如下 一组线程，每个线程都关联自己的AutoResetEvent & activity Thread1-Event1-activity1 Thread2-Event2-activity2

每个线程执行一个循环并在循环内执行一个操作。

伪代码如下。

因此，将操作排队到线程的控制器只需设置事件，线程完成其任务并返回等待activity-n的下一个请求

为了减少所使用的 WaitHandles 的数量，我想到的基础设施是在所有线程中使用一个信号量。

将信号量计数设置为 100 的任意最大值。将信号量的初始计数设置为 0。

现在信号量对于所有线程基本上都处于锁定状态。

现在所有线程都像以前一样执行循环

除了没有固定的活动线程（活动排队到集中并发队列）。将活动排队的控制器执行以下操作。

信号量实现会比多重 WaitHandle 方法更好吗？如果是，为什么？我确实觉得单一的信号量方法意味着增加的争用。

如果有人可以对此有所了解。那会很好。

更新： 我没有使用 BlockingCollection，因为我的请求队列有点独特。我的条件是我有多种活动（类型 1 到 n），并且当一个类型为 n 的活动被执行时，不能执行多个相同类型的活动（比如 n）。这就是为什么最初我每个活动类型都有一个线程。我试图将所涉及的等待句柄减少到 1，这就是为什么我试图查看信号量方法是否适合。但是我担心的是，如果我去信号量路线，我会增加锁竞争。在我的场景中，我可能随时有一个或两个线程处于活动状态，这意味着所有剩余的线程将争夺信号量中已打开的一两个开放槽。

Oracle Java 文档说：

java.util.Random 的实例是线程安全的。但是，跨线程并发使用同一个 java.util.Random 实例可能会遇到争用，从而导致性能下降。考虑改为在多线程设计中使用 ThreadLocalRandom。

表现不佳的原因可能是什么？

我有一个二叉搜索树的无等待实现，但我无法找出衡量线程争用的具体方法。这里的争用是指尝试同时访问同一块内存的线程数。

到目前为止，我已经搜索了 ThreadMXBean 和 ThreadInfo 类，但是由于没有涉及到锁，所以我还没有找到任何解决方案。