Re: Inter-processor atomic operationss

No, if those were in a region of address space where the same physical
backing store is used for both processes, you would be fine.

Since people appear to be misunderstanding what I was saying, let's be
clear - I am not saying that you should try to do this with a critical
section.

However, you could design a hypothetical synchronization mechanism that
works exactly the same as a critical section, and when placed in a region of
memory shared between multiple processes, it will work the same as if you
were using it with multiple threads in the same process. In fact, the only
difference between the implementation of this hypothetical synchronization
mechanism and a critical section would be:

1. Need to either always use a keyed event (XP/2003+) for the wait semaphore
or precreate the wait semaphore ahead of time. Trying to create the kernel
wait object on demand like critical sections do in cross process scenarios
is not particularly feasible.
2. Don't refer to any memory not in the shared memory region. Critical
sections do this for debug purposes (checking for orphaned critical sections
and linking to a debug structure that contains things like stack traces).

The only considerations would be the use of a common wait semaphore (e.g.
dispatcher waitable object) if you want to go into a dispatcher wait state
after a certain number of tries to acquire the lock (in which case you need
to make sure that each process has a usable handle to that object). This is
surely not an insurmountable problem and easy to accomplish in practice,
or - you could have the synchronization object just be a plain spinlock in
which case the implementation is even easier (though probably a bad idea, as
after a point spinning is only going to reduce performance).

There are of course downsides to such an approach, such as that you will be
using up address space in 64KB chunks unless you implement a scheme where
you have one shared memory region used for all of your hypothetical user
mode cross-process synchronization structures.

"Vladimir Scherbina" <vladimir.scherbina@xxxxxxxxxxxx> wrote in message
news:envqUZRSGHA.4456@xxxxxxxxxxxxxxxxxxxxxxx
Alexander,

As I understood Skying was relying on the fact, that content of
CRITICAL_SECTION is a simple data (DWORD, HANDLE) so there should not be
the problem when copying data to shared memory, but sure, LockCount,
RecursionCount will be usless in another process...

--
Vladimir
http://spaces.msn.com/vladimir-scherbina/

"Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote in message
news:%23rUFqURSGHA.3192@xxxxxxxxxxxxxxxxxxxxxxx
Critical sections may be linked to an in-process list and contain
in-process allocated memory. Putting it to a shared memory is very bad
idea.

"Skywing" <skywing_NO_SPAM_@xxxxxxxxxxxxxxxxxxx> wrote in message
news:eg$eiXQSGHA.1728@xxxxxxxxxxxxxxxxxxxxxxx
This isn't really why. If you put a critical section in a region of
shared memory, made sure the wait semaphore was created and duplicated
to both processes, then it would work.

(Of course, critical sections are not designed to do this - no
documented APIs to get at the wait semaphore. But it would work if you
forced the semaphore to be created early and then could safely get the
handle to duplicate it into the other process.)

"Vladimir Scherbina" <vladimir.scherbina@xxxxxxxxxxxx> wrote in message
news:OI5NERQSGHA.5552@xxxxxxxxxxxxxxxxxxxxxxx
To OP: in addition to Slava's post, critical sections cannot be used
for interprocess communications, because they're user mode objcts.

--
Vladimir
http://spaces.msn.com/vladimir-scherbina/

"Slava M. Usov" <stripit.slough@xxxxxxx> wrote in message
news:Op%23MmXPSGHA.4608@xxxxxxxxxxxxxxxxxxxxxxx
"Nadav" <Nadav@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:236CA1CA-2509-4344-8691-4E31F30B3529@xxxxxxxxxxxxxxxx
Hi,

I am developing a server that should work on a multiple CPU machine,
some
questions:
1. Does the Interlocked API set guarantee inter CPU atomic operations
or
JUST inter thread atomic operations.

How can you ensure thread atomic operations without ensuring CPU
atomic
operations?

2. The 'volatile' keyword assures that the volatile variable would
use a
register for interaction

Not even close. The volatile keyword ensures that access to a variable
will
not be optimized away by the compiler.

[...]

Is there any solution other then using the common sync objects (
critical
sec, mutex, . ) for inter-process atomic operations?

State the problem if you're looking for a solution.

S












.

Relevant Pages

  • Re: Inter-processor atomic operationss
    ... Putting it to a shared memory is very bad idea. ... APIs to get at the wait semaphore. ... Does the Interlocked API set guarantee inter CPU atomic operations ... JUST inter thread atomic operations. ...
    (microsoft.public.win32.programmer.kernel)
  • Inter Process Communication
    ... Two or several processes can exchange data through this resource. ... The shared memory ID is given as program argument. ... sem_create: creates a semaphore set. ...
    (comp.unix.programmer)
  • Re: Inter-processor atomic operationss
    ... APIs to get at the wait semaphore. ... duplicate it into the other process.) ... Does the Interlocked API set guarantee inter CPU atomic operations ... JUST inter thread atomic operations. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Inter-processor atomic operationss
    ... APIs to get at the wait semaphore. ... duplicate it into the other process.) ... JUST inter thread atomic operations. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Suggestions of design (contd.)
    ... The SNMP subagent creates a shared memory region and semaphore ... If a snmpget request comes then it needs to answer the desired ... but the safe functions are the minority out ...
    (comp.unix.programmer)