Hi Ocke, Hi André,
>>When should I use a Mutex in my functions?
>
> This question is discussed very often. :-) The best way is to use it in
> every* method which is public available.
That's a good level-0-approximation, but not really correct :)
Talking about multi-threading concepts would probably go too far here
(and there are books which explain this better than me :), but in
general, think of mutexes as a way to ensure ensuring object
consistency. At any time, only one thread can be inside any of the
sections guarded with the same mutex. As a consequence, you can, inside
such a section, become "temporarily inconsistent" in your object,
without affecting any other threads/clients - they will wait until the
guarded section is left, and at this point, you have usually restored
your object consistency.
So, yes, guarding your mutex at the beginning of every method is a good
start.
What you additionally need to be aware of is calling into other objects.
In general, calling listeners should be done without a locked mutex, as
this is very prone to deadlocks.
> * You don't have to use it when you only have a return statement like
> "return xParent;" or "return 42;"
That's not true. Consider
void setParent( const Reference< XInterface >& _Parent )
{
m_xParent = _Parent;
}
Reference< XInterface > void getParent()
{
return m_xParent
}
Since the assignment "m_xParent = _Parent" is not necessarily (read: not
guaranteed to be) an atomic operation, there is one or two processor
cycles where the value of m_xFoo is inconsistent. If, in this short
period of time, a second thread calls getParent, it might receive this
inconsistent value of m_xParent - and probably crash.
Thus, both methods need to be guarded with a mutex.
>>When can it happen that two
>>threads use "getTables()" or something like this?
>
> Inside office this isn't possible at the moment but when someone
> connects to the office, she can start as much threads as the system
> allows :-)
Also, insice the office there are scenarios where multiple threads are
involved. For instance, some form components notify certain events (such
as "mouse pressed on a form control") in a dedicated thread. Now when
the user binds an Basic macro to such an event, and from within this
macro, calls into your driver, then this call will also happen in a
non-main thread.
Also, the Java-UNO bridge makes extensive use of threads. Since a number
of wizards is written in Java, potentially every call from one of those
wizards (consider e.g. the form/report wizard) can happen in a non-main
thread, too.
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Database http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
