Operating System - OpenVMS
1748248 Members
3585 Online
108760 Solutions
New Discussion

Re: Is lib$movc3 "atomic"

 
rachid_c
Occasional Visitor

Is lib$movc3 "atomic"

I have process A and process B.

In process A, I want to use lib$movc3 to move a number of pages of memory from one location to another.

However, process B is periodically updating some of these pages of memory. If process B happens to try to update a page that process A is copying using lib$movc3, will the copy be successfully done (i.e. without partial updates by process B)?

Is lib$movc3 atomic?

8 REPLIES 8
GuentherF
Trusted Contributor

Re: Is lib$movc3 "atomic"

No! It never was even as an instruction on VAX architecture.

 

/Guenther

rachid_c
Occasional Visitor

Re: Is lib$movc3 "atomic"

Thanks... Maybe there is one clarification I should make (I'm sure it doesn't make a difference) ... in the scenario presented, Process B is also using lib$movc3 to modify a page of memory. 

Hein van den Heuvel
Honored Contributor

Re: Is lib$movc3 "atomic"

The answer is still NO, possibly: "No Way! What were you thinking?"

 

You need some sort of synchronization method. Probably a LOCK.

Check out the manuals (or help) for SYS$ENQ(w)

 

For  very low frequency (less than 1/second?) and lazy programming you could even consider expoiting an RMS record lock with the WAIT (RAB$V_WAT) option, allthough SYS$ENQ is not all that much harder to program

 

If you explain more of the context, then perhaps we can provide a better answer.

Things like 'how often', 'how much (data)', 'how many (processes)',...

What changes can be made? threading? implemenation language.

 

hth,

Hein

rachid_c
Occasional Visitor

Re: Is lib$movc3 "atomic"

Thanks for the difinitive answer :)

I know I could use a lock, but was wondering if I could get away without it for performance purposes.

 

Just to complete the picture:

We have Global Section A (GS_A) and Global Section B (GS_B)

Current Implementation:

1- Process A takes the lock on GS_A and copies a list of some memory pages from GS_A to GS_B and releases lock.

2- Process A then copies the pages from GS_B to disk.

3- Goto 1

 

 

I wanted to change so that:

Process B takes the lock on GS_A and copies a list of some memory pages from GS_A to GS_B and releases lock. At the same time Process A is copying the pages from GS_B to disk. I do not want to have a lock for the whole GS_B because writing to disk takes too long and Process B can't wait that long.

 

Hein van den Heuvel
Honored Contributor

Re: Is lib$movc3 "atomic"

Hmmm.. why use a second process, and (thus) global memory. 

Just start an thread in the local process to finish the disk write?

Can probably just use basic AST's to keep everythign alive and synchronized.

 

If you need that second process/second section, and do not want the copying of the next data to wait for the writing of the current buffer then you'll have to think about granularity. Don't lock the whole section (or do, but under there...) lock pages in the the section. If in use (locked), try for a next one?

I suspect you'll end up using a INSQTI to grab buffers from lists.

It has been done many times before.

Start with a list of free buffers in section B, and an empty  work list.

process A:

- Grab a buffer from free queue  fill it, release to work queue,

- $WAKE process B if work queue was empty

- if free queue was empty, enter self on wait queue node, and $HIBER.

 

process B:

- Grab a buffer from the work queue,

- do the work,

- release to free queue

- if free queue was emtpy then look in wait queue and $wake first entry

- Try to gran a next work buffer, if none then $Hiber.

 

No locks.

 

Hein

 

 

rachid_c
Occasional Visitor

Re: Is lib$movc3 "atomic"

Thanks Hein... I will think about that.

GuentherF
Trusted Contributor

Re: Is lib$movc3 "atomic"

You can also use LIB$BSSI and friends to use a flag in a quadowrd in that shared memory section to implement a semaphore (single bit lock). This is lightweight but the implementation typically is done in a tight CPU bound loop so the wait situation should better be very short.

 

/Guenther

John Gillings
Honored Contributor

Re: Is lib$movc3 "atomic"

Just to complete the already detailed explanation... even on ancient uniprocessor VAX systems, the only instructions which are atomic are those which are explicitly atomic, ADAWI, BBxxI, INSQTxI etc... Any instruction can be interrupted, for example, for a page fault. Other processes can execute while your process is waiting for the fault to complete. A MOVC instruction can involve many pages, and in extreme cases could incur many page faults and therefore be interrupted many times.

 

Always take the worst case assumptions about process synchronisation.

A crucible of informative mistakes