Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Mutex with ActiveX exe

3 views
Skip to first unread message

Ophir

unread,
Dec 24, 2004, 3:00:05 AM12/24/04
to
Hello all

Two questions:
1. How much resorces does a mutex object use, in terms of 'Very
Much','Moderate','very little'?

2. I have this situation:

Object A is running in it's own thread ( ActiveX exe with thread per
object option)

Object B also running in it's own thread.

Both of them use a timer event to do some work like this:

Timer_Event_Object_A:

Do somthing

Raise event for object B

End event

Timer_Event_Object_B

Do somthing

Call a property of object A

End Event

I want tro use a Mutex object in the start of the Timer events so when
object A is in the timer event and there is a change in context object
B will wait until object A has finished it's timer event and vice
versa.

The question is will it work since each object calls properties or
raise event to the other object.
Is there a chance of creating dead lock here?

Also regarding the first question - I can have multiple objects
arranged in that manner and I want each pair to have it's own mutex
object - since only the pairs are related but have no relations witrh
other pairs - so will it overload the system?

Thanks
Ophir

Tony Proctor

unread,
Jan 5, 2005, 8:38:37 AM1/5/05
to
Mutexes and semaphores can both be used for this type of synchronisation.
Unlike 'ciritical sections', mutexes and semaphores are kernel objects, and
have system wide handles stored in a handle table. The size of this table
may grow dynamically. Here's a snippet from MSDN on the subject:

"Finally, there is no hardcoded limit on the number of entries a handle
table can have. A handle table maintained by the executive may grow
dynamically if necessary; thus, the number of handles that can be allocated
per process depends only on the memory available on your machine. (Note that
Windows NT may further limit this number on a per-user basis by reducing the
user's quota on nonpageable memory.)"

Critical sections are more commonly used for synchronisation between
threads, and are the most efficient mechanism. However, they rely on having
areas of memory shared between those threads, and VB tries hard to make sure
no memory is shared between any of its threads in order to reduce the need
for programmers to worry about synchronisation (even Module globals are
duplicated for each separate thread). Hence, if you can engineer it then
critical sections are the most efficient in both access time and resource
consumption.

I've always used mutexes and semaphores with VB because they're a lot easier
in a multi-threaded enviroment. These objects are really designed to cope
with inter-process synchronisation (which is why their handles are
system-side) and so they're slower than critical sections.

If a thread is waiting on one of these objects then it will not be handling
events. Hence a deadlock can result if another thread calls one its methods.
It's possible to perform a "lazy wait" on these objects though. Rather than
a full blocking wait, this would wait for a small interval of time. If it
returns with a timeout error (i.e. object was not released) then it gives
you the oportunity to call DoEvents before retrying the wait. However, be
very careful that this doesn't cause your code to recurse.

Tony Proctor

"Ophir" <oph...@netvision.net.il> wrote in message
news:1103875205.9...@z14g2000cwz.googlegroups.com...

0 new messages