Sign in to follow this  

Concurrency Nomenclature

This topic is 4817 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What do I call a concurrency object that allows one thread to open it at a time but can allow nested opens / closes by that same thread. eg: thread 1 opens BLARG thread 2 blocks waiting for BLARG thread 1 opens BLARG (2 opens) thread 1 closes BLARG thread 1 closes BLARG thread 2 wakes and enters BLARG This isn't like a semaphore because it allows only one thread, but it isn't a mutex either because it counts. Why? because I have critical sections of code and the user of the critical sections is allowed to open the mutex to encapsulate all critical sections inside one critical section. eg: user opens BLARG user calls external BLARG-critical function 1 user calls external BLARG-critical function 2 user calls external BLARG-critical function 3 user closes BLARG The external functions open and close BLARG, and are not written by the user but by me. Any idea what I should call this, or whether I should use something else?

Share this post


Link to post
Share on other sites
You use critical section for that.

thread 1 enters CriticalSection
thread 1 opens BLARG
thread 2 waits on CriticalSection
thread 1 closes BLARG
thread 1 opens BLARG
thread 1 closes BLARG
thread 1 opens BLARG
thread 1 closes BLARG
thread 1 leaves CriticalSection
thread 2 continues.

You can encapsulate this behaviour in a monitor.

(I edited soon after I posted it in hopes that the thread would not be affected. Unfortunately, it was. Apologies for that.)

[Edited by - flangazor on October 8, 2004 6:43:02 AM]

Share this post


Link to post
Share on other sites
That would be called a deadlock if it were a mutex. I said that the object allows nested opens.

EDIT: Message this referred to has disappeared.

[Edited by - Krylloan on October 8, 2004 5:44:32 AM]

Share this post


Link to post
Share on other sites
Is that the case with linux also?

I'm assuming that if you open the windows mutex multiple times and close it once it is immediately closed, eg it doesn't count. Is that right?

Thanks

Share this post


Link to post
Share on other sites
Thanks flangzor, but the problem I have is that the user doesn't need to perform the encapsulation.

this is also ok:
user calls external BLARG-critical function 1
user opens BLARG
user calls external BLARG-critical function 1
user closes BLARG

external BLARG-critical function 1:
external opens BLARG
external performs operations on BLARG-protected variables
external closes BLARG

I realise I am going to have to create this functionality using a supported concurrency object. It is quite easy to enforce the above using 2 mutexes, although it's not wonderfully efficient unless the mutexes are superfast.

Share this post


Link to post
Share on other sites
Under linux, using pthreads, there's a parameter you pass that tells the system whether you want the 'recusive' behaviour or not.

On windows, every call to WaitForSingleObject requires a corresponding call to ReleaseMutex.

If by "open" you were talking about the call to CreateMutex, then each call to CreateMutex returns a different handle (to the same object, assuming you're passing in the same name) and so you need to call CloseHandle on each one to close the actual underlying object.

Share this post


Link to post
Share on other sites
Given the way that your original post was written, I thought you might be trying to write multiple transactions to a database in one thread before another thread can access the db. By 'open' I thought you might mean 'open a write context.'

With regards to speed of Mutexes, you may like to look up Spinlocks.

Share this post


Link to post
Share on other sites
Quote:
Original post by Krylloan
[...]I realise I am going to have to create this functionality using a supported concurrency object. It is quite easy to enforce the above using 2 mutexes, although it's not wonderfully efficient unless the mutexes are superfast.
If you only need these locks to work within a single process in windows, a CriticalSection would be the way to go. They allow nesting and DO count so you need one 'release' for each 'acquire'. With reguards to speed - I had a class with tons of functions being called by several threads (some of the threads were multimedia timers that needed 1-ms accuracy), and putting a critical section around each function in the object didn't slow things down at all.

You just need to be smart about it. For example, instead of doing
Func1()
{
Func2ThatAcquiresAndReleases();
Acquire();
//DoStuff
Release();
}
you'd want to do:
Func1()
{
Acquire();
Func2ThatAcquiresAndReleases();
//DoStuff
Release();
}
because the second version only has to wait for the criticalsection a single time, while the first version has to wait twice.

Share this post


Link to post
Share on other sites
Thanks. Looks like both CriticalSections and mutexes both do exactly what I want them to. I'll probably go with CriticalSections as I'm only using one process and since this is part of an API, efficiency is always a consideration as it is unclear how often the user may use any functions.

Looked up spinlocks. They could possibly work but the idea of using a busy/waiting loop just spins me the wrong way. And monitors seem a bit too bulky, but thanks for the ideas.

Share this post


Link to post
Share on other sites

This topic is 4817 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this