I am using semaphore to signal the producer thread that another (consumer) thread has completed the shared data/object processing. But is there a limit for overall amount of semaphores instances I could create? I’d like to understand, is it ok to use such a synchronization for a large (hundreds of thousands) number of objects? Please notice, it's another question - not about "what is the maximum number of permits semaphore could have", so ity is not a duplicate. Thank you
Asked
Active
Viewed 176 times
0
-
2I think the OP means how many instances of Semaphore can they create. – tgdavies Nov 09 '20 at 03:05
-
Why? Why not use a queue? – user207421 Nov 09 '20 at 03:09
-
How could producer thread understand, message has been processed? – BUKTOP Nov 09 '20 at 09:31
-
I supposed it’s clear, sorry. Edited question to clarify – BUKTOP Nov 09 '20 at 10:26
-
Isnt a `Future` better for this ? – Felix Nov 09 '20 at 11:05
-
Semaphore is much simpler as i need to wait for processing result in the same method that produced a shared object – BUKTOP Nov 09 '20 at 11:09
-
Hey, I didn’t ask for maximum permits, i asked about maximum instances! It’s a different question, do you understand that??? Wtf... – BUKTOP Nov 09 '20 at 14:55
-
Can you share more details? What exactly do you mean by "maximum instances"? – Nico Haase Nov 17 '20 at 14:14
-
@NicoHaase new Semaphore(); – BUKTOP Nov 17 '20 at 14:18
-
That's a single instance - so what's your question about this? – Nico Haase Nov 17 '20 at 14:48
-
@NicoHaase Sorry, I don't understand, are you kidding or what? Vector
v=new Vector(); while(true) v.add(new Semaphore()); – BUKTOP Nov 17 '20 at 14:51 -
@NicoHaase there's an answer and discussion below, just read it, and everything will be clear – BUKTOP Nov 17 '20 at 14:54
1 Answers
2
It's undefined how many object instances you can create in Java. That depends on available memory.
It's undefined how Semaphore is implemented. If your platform imposes a limit it is probably higher than the hundreds of thousands you're proposing.
You can obviously just try it! Write a stub program that just allocates Semaphores and puts them in an ArrayList (to avoid them getting garbage collected) and see what happens.
Hundreds of thousands it not a 'scary' number in most environments but there are parsimonious ways of managing the object populations. For example, 'lazy initialisation'. Allocating a Semaphore on first acquire (or release if doing count up) and nulling the reference when it reaches zero is a a potential strategy for only having instances that 'in play' is a possibility if you need lots of 'logical' semaphores by in practice few of them will have a non-default (e.g. zero) number of permits in circulation.
Persixty
- 8,165
- 2
- 13
- 35
-
Usually ipc semaphores amount is limited in the most oses, I understand these semaphores ain’t ipc, but asked to be sure. Thank you! – BUKTOP Nov 09 '20 at 11:05
-
@BbIKTOP: I've corrected my answer. I wasn't aware of a limit and have created millions of mutexes and never got stuck. What I do know is that the Object monitor (that all objects have!) is typically 'lazy initialised'. That's half parsimonious! Objects are allocated without a monitor and one is allocated if they need it - but never unallocated. If the JVM is using an OS construct 1-for-1 with Semaphore I'll be surprised if it isn't doing something similar. But you of course could anyway. – Persixty Nov 09 '20 at 12:22
-
1@BbIKTOP Here's some code that creates, acquires, checks and releases 10,000,000 Semaphores very quickly in a toy environment: https://ideone.com/KHmqpO That doesn't prove anything but it suggests you don't have a problem. I've made sure to release all permits before the Semaphore is inaccessible. In principle that's harmless but code that doesn't can turn into a permit leak later. Not all leaks are memory leaks. – Persixty Nov 09 '20 at 12:36