mutex for multiprocess synchronization

[YE LIU_1]

Dear VMS Users,

May I know what is the fastest mutex (or RW Lock) for multiprocess synchronization on Itanium2?

Thanks,

YE LIU

[Hein van den Heuvel]

The fastest is a shared memory spinlock interlock.

Typically more than adequate is just using the OpenVMS Lock Manager (SYS$ENQ())

Some folks even use a record in an indexed file.

What are the detailed requirenments?

How many handof per second expected?
Any data to convey during the handof?
What level of process crash protection?
User code, or kernel code?

Hope this helps some,
Hein

[YE LIU_1]

I observed that the Interlock operation takes very long percentage of time compared to Alpha when we ported it to Itanium. Could you post the API or system call, because the interlock call is implemented in assembly language on Alpha. I suspect that it does not work well on Itanium.

Thanks,

YE LIU

[Hein van den Heuvel]

Ok, so this is not a 'random' question, but you have a real problem to solve.
Clearly you have MUCH more information to share. Please don't 'waste' our time making us guess and speculate. Provide some numbers, some code in an attachment, explain what has been tried, Explain what 'much longer' means in your universe, explain the observation tools used thusfar.

Note, this problem may well be beyond the scope of a helpful attempt here. Depending on you time and resources you may want to consider professional support for this challenge. There are several folks out there, and even withing the readership of this forum, which are qualified the help with these kind of jobs.

Best of luck,
Hein van den Heuvel ( at gmail dot com )
HvdH Performance Consulting

[Robert Brooks_1]

Answering Hein's questions first will get you a better response, as would posting the code you are attempting to use for synchronisation.


-- Rob

[Hoff]

The fastest? That would be no lock at all. And yes, that can be entirely possible. Careful writes, and avoidance of word tears and such.

Further, what is technically the fastest approach might be a wildly incorrect solution for the problem as -- by the time the designer and the programmer are done contending with the implications of the technique and with the design and implementation and the debug and the support costs -- the solution can be more expensive than using a solution that implements the requisite features.

For instance, cluster-wide shared RMS files (with global buffers enabled) can be the best available solution for shared storage. Even though shared memory is faster, and other synchronization techniques seem preferable. By the time you get done dealing with all of what RMS deals with on your behalf, you can end up with a big and hairy code-base that you now have to maintain and upgrade.

If you want to maintain your own versions of spinlocks, the distributed lock manager, RMS cluster-aware processing and/or other such synchronization tools, have at. It can be a career, even once you get the debugging and the race conditions solved.

[John Gillings]

YE,

In terms of code path, Hein's suggestion of spinlocks is certainly the fastest, BUT if the code will ever execute on a uniprocessor system, you have to add priority equalisation (to prevent starvation), which will slow things down. Assuming the syncronisation points are sparse, with low contention and short critical regions, then spinlocks will probably give best performance with least overhead. However, if you have a high contention and/or long critical regions, spinlocks will generate lots of MPSYNCH like activity spinning for a lock, in which case you're probably better off using cluster wide locks.

From an application perspective, the best thing you can do is design an API which describes your "ideal" synchronization primitives. Write your application in terms of those primitives. You can then implement the API using any mix of the underlying mechanisms provided by OpenVMS, and, if necessary, change the mechanism without having to change the application. This also provides you with a mechanism to easily compare different mechanisms, and to port the application logic to other platforms which provide different mechanisms or different performance balances (like Alpha - Itanium).

[YE LIU_1]

Thanks everyone for the reply.

YE LIU

[YE LIU_1]

Thanks for the reply.

[Jan van den Ende]

Ye Liu,

please review

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

for the way to say "Thank you" here.

Proost.

Have one on me.

jpe