SignalRGB error message

Blazerg

New Member
I use Hwinfo to see my system stats on a sensor panel screen.
I also use signalRGB to control my pc leds.

The thing is, Hwinfo works but I keep getting this error or warning message, what does it mean exactly?

1738348696830.png
 

Attachments

  • 1738348637953.png
    1738348637953.png
    87.1 KB · Views: 1
Isn't the explanation in the dialog sufficient?
Hi Martin, thanks for answering and apologies if the question is dumb, I am not very smart with these things.

I understand from the dialog that hwinfo can't access something due to signalrgb accessing the same sensor (I guess). But I only use signalRGB for controlling the leds, so I don't understand the conflict. On the signalRGB side they tell me to uninstall hwinfo and in the hwinfo side they tell me to uninstall signalRGB.


Does this mean that I need to choose between controlling temps or leds but both things are not possible?
 
It is possible to run both apps but it won't be optimal and HWiNFO might appear sluggish.
IMO there's no reason for signalRGB to hold that lock for excessive time. They should fix this rather than asking users to uninstall other software. I'm not even sure they know what's the purpose of that lock and if they know what they are doing.
 
Hi Martin, thanks for your answer again. I understand your point that may be a bad code on signalRGB side so I decided to give an opportunity again to icue to control my leds and I got the same error but for icue this time =(
1738371012947.png

I still don't understand the issue because I don't want to see any temps from either icue or signalRGB, I love hwinfo for that, I just want to control the pc leds and both programs seem to produce this conflict...
 
The issue is that there are certain hardware interfaces that must not be accessed by multiple applications at the same time. Otherwise it could result in a collision and crash.
So several vendors have agreed on certain global synchronization objects (locks/mutexes) to manage access to such interfaces. When an app is going to access such interface, it first checks whether the object isn't used by anyone else. If it is, it waits until it becomes free, otherwise it acquires the lock, does the job and releases it.
If an app is waiting for the lock (because another one has it claimed), it can become stalled because it sits idle and cannot do its job. You're getting that warning because HWiNFO thinks it's waiting too long for another app.
HWiNFO started to show this warning because these locks became used by many apps from different vendors and we have found cases of improper implementation in some software that was resulting in very long blocking of other apps. We require fair use by all vendors so that their apps minimize locking out others (don't hold the lock for excessive time).
It's similar as if a road semaphore would remain red all the day just because some priority cars are expected to be passing sometime that day.
 
Back
Top