Is lib$movc3 "atomic" (393 Views)
Reply
Occasional Visitor
rachid_c
Posts: 4
Registered: ‎03-07-2013
Message 1 of 9 (393 Views)

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?

Trusted Contributor
GuentherF
Posts: 239
Registered: ‎10-04-2006
Message 2 of 9 (379 Views)

Re: Is lib$movc3 "atomic"

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

 

/Guenther

Occasional Visitor
rachid_c
Posts: 4
Registered: ‎03-07-2013
Message 3 of 9 (350 Views)

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. 

Honored Contributor
Hein van den Heuvel
Posts: 6,588
Registered: ‎05-19-2003
Message 4 of 9 (341 Views)

Re: Is lib$movc3 "atomic"

[ Edited ]

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

Occasional Visitor
rachid_c
Posts: 4
Registered: ‎03-07-2013
Message 5 of 9 (335 Views)

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.

 

Honored Contributor
Hein van den Heuvel
Posts: 6,588
Registered: ‎05-19-2003
Message 6 of 9 (329 Views)

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

 

 

Occasional Visitor
rachid_c
Posts: 4
Registered: ‎03-07-2013
Message 7 of 9 (323 Views)

Re: Is lib$movc3 "atomic"

Thanks Hein... I will think about that.

Trusted Contributor
GuentherF
Posts: 239
Registered: ‎10-04-2006
Message 8 of 9 (319 Views)

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

Honored Contributor
John Gillings
Posts: 2,995
Registered: ‎07-31-2003
Message 9 of 9 (296 Views)

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
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.