| > Extend the queue class, add a mutex member variable, lock and unlock it in
> all the access methods for the queue.
Oh good, I'm on the right track! I've done all the above except manage
to make the mutex a member. My problem is that I don't know where to put
pthread_mutex_t my_mutex = PTHREAD_INITIALIZE_MUTEX
Is there some other way of initializing it so that I can declare it in
the class definition and then initialize it in the constructor?
Thanks for the feedback Mike,
Iain
> Regards, Mike
>
> Original Message:
> -----------------
> From: Iain Duncan iainduncan@telus.net
> Date: Thu, 04 Aug 2005 00:10:21 -0700
> To: csound-devel@lists.sourceforge.net
> Subject: [Cs-dev] mutex's in classes
>
>
> i know this is not strictly on topic, but it's for a csound front end,
> so hopefully someone can lend insight.
>
> I have a message queue will hold all input messages headed for the
> csound controller, be they midi, keystrokes, fl_events, network
> messages, etc. It's implemented in a class so that ideally the
> programmer using it can just go
>
> my_msg_qu.push(&new_message)
>
> without having to worry about the threading. The class method will lock
> the mutex and unlock, and the queue class can provide blocking and
> non-blocking ( failing ) methods as well. i think I need only one mutex
> to protect the whole queue 'cause I can't see input coming fast enough
> that it will matter too much if other input threads block for a tiny
> bit. I don't think any should starve under normal use. My questions:
>
> - Should the mutex be a global variable, or is possible to have it be a
> class private data element? If so, how is this properly done?
> - of the mutex is a global variable, where should it be declared? In the
> header file for the queue class or in the main file?
> - If fltk runs in only one thread, that should be present no problems
> correct?
>
> Once I have the basic architecture hashed out doing a very very simple
> example of all intended directions of i/o, it would be great if someone
> who knows this stuff wouldn't mind looking at it. I'd like to not waste
> time writing tons of code with a crappy architecture! =)
>
> Thanks
> Iain
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |