koobas.hobune.stream
Thread semaphore in webplayer
I need to use a semaphore for limiting a class resource.
The thing is that my game sometimes needs to more than 20 web calls to an API. If I don't create a separate thread for each one, the client looks locked for ~5 seconds until all calls are made.
After making one thread for each call, the problem I had then is that in the extreme case I have to send ~50 API calls, I get an exception of too many sockets open, and that's when I decided to use a semaphore.
This semaphore is inited to 10, and everytime a thread wants to make an API call waits for it, and then it releases it. In this way, I have at most 10 API calls in the same time.
Now I tested it in the webplayer (which will be the release platform) and I get a security exception for using semaphores. Anyone knows a clean way to solve this? [something close to a semaphore...]
Dirty hacks I thought was to make a single thread with a queue on it, and this thread is responsible of processing his own queue by sending the calls 1 at a time (but that'd be slow, and I have to handle a lock for the queue).
And the other it's similar to this. Split all the API calls that needs to be made to 10 different threads. The problem is that if they haven't finished, and I have to send them again, then i'd have 20 threads again. And also, having multiple queues with multiple locks it's a call for deadlocks.
So.. any thread-safe non-blocking solution?
Now i'm trying to implement my own semaphore by using the class $$anonymous$$onitor. Have to test if it's available in the webplayer.
When doing multithreaded stuff and there's a limited resource, I would think it's better to have only one (or as many as the resource allows) thread access the resource. At least to me, having one thread access a resource is more logical than having a hundred threads compete over access to that resource...
This could be achieved with e.g. a thread-safe queue of jobs to perform on the resource that all other threads write to and only one worker reads. The worker reads the next job in the queue, performs it on the resource and returns a result-object. Easy enough (I would imagine) to do with delegates and databases, where the result is always a DatabaseTable or some such.
My solution: implement my own semaphore, that I think it's clean. Not sure it's completely safe, so use it at your own risk.
It's a shame though that they don't let you use semaphores "Because of security" and I have to end up implmenting my own semaphore, that's most probably to be thread unsafe. The chances of having a deadlock here are way greater than using the standard's C# library. Oh well...
private object _lock;
private int max;
private int count;
public MySemaphore(int maximumCount)
{
_lock = new object();
max = maximumCount;
count = 0;
}
public void WaitOne()
{
bool green = false;
bool haveLock = false;
try
{
Monitor.Enter(_lock); // Get the lock
haveLock = true; // Monitor.Enter should have a 2nd parameter to make this operation atomic. Dammit unity...
while(!green)
{
if(count < max)
{
count++;
green = true;
}else if(count == max){
Monitor.Wait(_lock); // Release the lock and wait for a change. Then reaquire the lock
}else{
Debug.LogWarning("Semaphore broken."); // This should not be called. If it is, the semaphore is broken. Threading is hard...
Monitor.Wait(_lock);
}
}
} finally {
if(haveLock) Monitor.Exit(_lock); // Release the lock
}
}
public void Release()
{
bool haveLock = false;
try
{
Monitor.Enter(_lock); // Get the lock
haveLock = true;
count--;
Monitor.PulseAll(_lock); // Send a signal to everyone waiting that the count has been decreased.
} finally {
if(haveLock) Monitor.Exit(_lock); // Release the lock
}
}
