Each queue has its OWN mutex. It locks it when a calling thread starts doing 
something critical (beginning of the queue access, for example). Another 
thread tries to lock it, and fails and waits. The first thread finishes its 
critical work (finished accessing the queue, for example), and unlocks the 
queue. The second thread is then free to proceed. This is called a "critical 
section".

Regards,
Mike

----- Original Message ----- 
From: "Iain Duncan" 
To: 
Sent: Saturday, December 03, 2005 10:12 PM
Subject: [Cs-dev] Question about locking queues/processor.


> While not strictly to do with csound, this is for my csound front end 
> project. I understand using queues to share data between threads, and 
> protecting the queue with a mutex. In this context I have some high and 
> low priority threads ( ie csound vs userinput vs display ) using pthreads. 
> Is there a way for one to guarantee that a section of code, once entered, 
> gets finished? Can I essentially make writing to a queue atomic? I would 
> like to make sure that once a thread starts a queue push or pop it won't 
> get interrupted at all.
>
> I figure one obvious solution is to have a global mutex that only one 
> thread can ever have, and if a thread needs to be guaranteed not to be 
> interrupted, it can just keep this mutex. But perhaps there is a more 
> elegant way that will avoid the potential overhead of a bunch of context 
> switched while higher priority threads try for this mutex and fail? Is 
> there a mechanism for a lower priority thread to temporarily pre-empt 
> everything else for the duration of this queue operation?
>
> In other news, tests of the multi-user real time front end design are 
> going well, and it's going to be hella cool for gigging with csound5! =)
>
> Thanks
> iain
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Each queue has its OWN mutex. It locks it when a calling thread starts 
> doing something critical (beginning of the queue access, for example). 
> Another thread tries to lock it, and fails and waits. The first thread 
> finishes its critical work (finished accessing the queue, for example), 
> and unlocks the queue. The second thread is then free to proceed. This 
> is called a "critical section".

That's exactly what I'm doing, so I guess that's good news. I have the 
queue operations as methods of objects that containg mutexes for that 
queue, so if my midi input stream ( which has a pointer to the 
controller module ) wants to put a new message into the controller, it 
calls

p_controller->push( in_msg );

were the controller.push() method locks an internal private mutex before 
putting the message on it's internal queue. It then deals with that 
message the next time the thread containing the controller's main 
execution gets to run. Sound right?

What I was wondering is whether there is someway to actually prevent the 
context switch from happening at all during that section, to reduce the 
useless overhead of a context switch that can't accomplish anything. Am 
I fantisizing?

Thanks
Iain



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net