First time poster - apologies if I am missing key information.

I am working on a project composed of two applications which rely on a USB license supporting concurrent licensing (e.g. only 10 users can access component x at the same time, between the 2 applications).

The USB license supports a mutex for accessing read/write functionality, but I am struggling on coming up with a model that would allow the two applications to communicate with one another to determine how many users are logged in total between the two applications.

In other words, if the USB dictates 10 users max, and application #1 has 2 users logged and application #2 has 8 users logged in, how can both applications know that an 11th user should not be allowed to be logged in?

The best I have come up with is to use a Mutex for an integer representing current users on a computer. When a user attempts to log into either application, that integer is checked. If user is allowed to login (because current # of users logged in < # of users licensed), then either application will allow this by modifying the mutex by incrementing it by 1.

And, when a user logs off the application, the application will decrement the mutex by 1 (releasing a "seat").

But, my concern then is if an application encounters an exception or a user force-quits an application that prevents it from calling the decrement, how should a "ghost occupied seat" be handled? (e.g. 5 out of 10 users were logged in, application crashed, mutex still says that 5 users are logged in when there's actually none).

1 Answer 1


Shared Event Log

Have the two programs share an event log. Each of them writes login and logout records.

These can be counted to determine current login population.

The two programs have to write a still alive message periodically (either per logged in user, or per application, or both).

While counting a login is auto logged out if the login/application keep alive wasn't seen within X minutes.

The application maintaining these logins will have to respect the auto logout (even if the user is still logged in) and either re-login the user, or log them out.

Named Semaphore and a named Mutex

One named Mutex, and One named semaphore per application.

Acquire the mutex, then read all counts on each named semaphore (treat non-existent semaphore as zero). Update the semaphores, and release the mutex.

If a failure occurs, then worst case is a system restart.

Alternately have a reset application that kills your apps, closes these named semaphores/mutexs and then restarts the closed applications.

Don't do it, its not your hardware.

If you absolutely must maintain a license limit, get them to connect to your server to obtain a certificate for a period.

This way you can provide say year long certs, for offline use, or 4hour certs to provide a floating licence.

This way also allows you to provide flexible licensing. In the sense of paying for a license per day, as many licenses as needed on that day. Which is a win for many businesses.

Also why DRM?

Generally speaking, why are you enforcing licensing by using what is a DRM.

Software does have a maximum user limit based on internal decisions, hardware limitations, and bandwidth. Also users themselves are usually limited in the number of applications they can simultaneously use. That is one program that they can focus on at a time, and any long running background tasks they already started.

Getting in the way of a user's focus change causes irritation to that end user. The competitor which doesn't have this limitation will generally be preferred by such users. Students particularly are sensitive to this, have the time to search around, and will become the user base.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.