Synchronization Variable Storage

Question

5.00/5 (1 vote)

See more:

We know that all the threads in process share the process address space.
We have various synchronization mechanisms like semaphore, mutex, spinlock, critical sections etc . used for thread syncronization.

I want to know in which part of the process address space are these synchronization variables stored?
How one thread gets access to the syncronization variable declared in another thread? Pls correct me if this question is improper.

Posted 8-Nov-11 3:07am

rupeshkp728

Add a Solution

Comments

Sergey Alexandrovich Kryukov 8-Nov-11 11:51am

My 5 for good thinking. Fortunately, OS takes care of this problem, but it did exists for the system programmers who created those implementations of synchronization primitives.
--SA

3 solutions

Solution 3

This part of phrase found in the question is not correct: "...declared in another thread". A variable of a synchronization primitive is never declared in a thread; only the stacks and the preserved CPU context belong to a thread; all other variables are shared between threads. Access to an object and threads are completely orthogonal categories. The only problem is the parallel access to the object by different threads.

One more clarification: strictly speaking, shared address space is not the address space of a process, but of an Application Domains. Each two Application Domains of the same process are isolated from each other as well as two different processes.

—SA

Posted 8-Nov-11 5:56am

Sergey Alexandrovich Kryukov

Updated 8-Nov-11 5:59am

v3

Comments

Chuck O'Toole 8-Nov-11 14:14pm

Well, "declared" is rather ambiguous, does he mean the "actual location of the statement the defines the variable" or the "creating of the object (e.g., CreateEvent()) in another thread"? It turns out that it's really not important where / which thread does the "Create" function, the object created (via its "handle") is visible to the entire process / thread family. What is important is the "scope" of the reference to the variable, could be global, could be passed by value (HANDLE) or could be only scoped to be referenced in one thread. So if you're going to look at this as a 'newbie' type question, you have to allow for the imprecise use of "declared" to mean more than the placement of the variable name.

Chuck O'Toole 8-Nov-11 14:27pm

Hummm, Application Domains are a relatively new concept for me, I'll have to read up on those to understand how the addressing / process context works out to allow for multiple applications to run within the process family. Something new to figure out.

Sergey Alexandrovich Kryukov 8-Nov-11 14:46pm

The concept is fairly simple -- address spaces are isolated per Application Domain, by default, only one is created for you, and in this case all your knowledge is totally applicable; almost the same if there are more: Application Domains are composed in the process and are the unit of address space isolation, not the process. Threads, however, can run throw the boundaries between Application Domains, as method addresses are all static and shared. This could be derived logically from all of the above. But if you are using a delegate instance, for example, this is data, and this instance makes no sense beyond the boundary of Application Domain. This is all pretty simple. Main application of Application Domains I know is the ability do unload a plugin. It is not possible to unload any separate assembly (Microsoft could not guarantee process integrity if one could), but one can unload the whole AppDomain with all assemblies loaded inside it. I think it's pretty clear.
--SA

Chuck O'Toole 8-Nov-11 15:32pm

Well, I understand the notion of separation of "access rights" within the domains, almost a "C2 level" separation with rights. I also get the idea of "marshalling" the arguments that cross the API calls. However, the documentation / description talks about "starting and stopping other Application Domains" almost as if they were separate execution "entities" within the process. Now if all that means is "loading" or "unloading" assemblies, then I get it. It's just the reference to "start / stop" that bothers me. I also read about "separate virtual address space" in the domains. The question is, does the address ranges overlap? That is, are they really separate address spaces or is the one big address space broken up into multiple "protection zones" that only certain domains can access (the rights thing). If it's just protection zones, then I get that too, using "portal instructions" to jump from one level of access to another. Otherwise you are dealing with an entire duplicate memory management system for each domain within a process and that's something I'd have to figure out.

Sergey Alexandrovich Kryukov 8-Nov-11 18:24pm

I don't really understand what "starting" and "stopping" do you mean. Could you post a reference? Perhaps I could explain it. I must say some Microsoft documentation on this topic fails to explain the essence of things going into rather confusing considerations. In particular, the threading aspect explanation was explained like that. I thinks the memory "protection zone" issue is pretty simple: a domains of access references (note, they are based on virtual memory addresses but not exactly the same as there is an intermediate level of indirection between them, the domain of GC; objects are not just garbage-collected, they can be relocated) is Application Domain, not process. An Application Domain accesses only the references inside the same AppDomain, everything else is IPC.
--SA

Solution 1

For multithreading in VC++/MFC, you need to use AFXBeginThread function. Whose first pararmeter is pointer to global function, prototype is,
UINT FunctionName(LPVOID param);
And second paramater is value to send through param.

You can send any data you want to access through param.

Posted 8-Nov-11 3:13am

Pranit Kothari

Comments

rupeshkp728 8-Nov-11 9:19am

Hey pranit this does not seem to be the answer for my question

Chuck O'Toole 8-Nov-11 9:48am

Well, technically he did answer this part of your question "How one thread gets access to the syncronization variable declared in another thread?" so don't be too harsh :)

Sergey Alexandrovich Kryukov 8-Nov-11 11:57am

This expression "...declared in another thread" in invalid. Even though I voted 5 for the question, I tried explain why this is invalid in my solution.
--SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Chuck O'Toole · Accepted Answer · 2011-11-08T03:47:00

Ah, address space. There is one and only one address space that belongs to you. All things yours live in that address space.

Now, the address space can be looked at as if it is partitioned into different uses.

Code, the execution path, generally read-only. Some code comes from your executable, some from DLLs, some from shared libraries, etc but it's all just code sitting in your address space.

Constant data (strings, const, things like that), also generally read-only.

Global Memory, a place where your "module wide variables" go, things declared in the scope of the program / cpp file and are visible to all functions. May or may not include the "extern" declaration.

Heap / Pool, read/write memory you can allocate things out of (new/delete and/or malloc/free). Basically, all your dynamic stuff.

Stack (one per thread) where local variables go.

In general, all of this can be seen by all threads in your application and some can change "roles", for example, some of the best known virus entry methods is to convince some poorly written piece of code to execute data as if it were code, but I digress.

You can either access things directly by name or pass pointers or structures / objects around as parameters between functions.

The only thing you have to be careful of is passing the address / pointer to a variable that lives in the stack space of a function / thread to another thread. While the pointer will most likely remain valid, the contents should not be trusted. So don't do that.

Oh, the only other "only thing" is to not pass pointers / addresses of things you eventually "delete" or "free" since again, the pointer is most likely valid but the data cannot be trusted anymore.

Oh, and I'm sure there are other "only things" out there so be careful.

---------------------------
Edit just to remove some potential confusion
---------------------------

Now there are two ways to interpret your question

Quote:
I want to know in which part of the process address space are these synchronization variables stored?

1) The object you create, that is the "HANDLE" that identifies the semaphore / event or object for the critical section, and the answer would be "in your address space" so you can access them, pass them around, etc.

2) The object that represents the thing you can wait on, the queue of waiters, etc. Those are "kernel objects" that live in the kernel's memory space, are "mapped to" by the HANDLE you get back from the create statement, and provide all the stuff the kernel needs to provide you the functionality of "Wait", "Signal", etc. You only indirectly reference these objects through the API defined and with the "HANDLE" given to you.

This separation is true for just about any OS, be it Windows or some unix like offering the POSIX thread synchronization features.

Synchronization Variable Storage

3 solutions

Solution 2

Solution 3

Solution 1

Add your solution here

Preview 0

Existing Members

...or Join us