What is the difference between named and unnamed semaphores?
For Example in Windows, we always do WaitforSingleObject( wait) and ReleaseSemaphore( Signal ) using the HANDLEs and not using names.
An unnamed semaphore can only be used by its handle, but if you have a named semaphore you can create a second handle using the name. The benefit of this is that you only need to have a static name to be able to use the same semaphore in different threads and processes.
Related
The situation is that: I have a function F1 which write into a buffer and the buffer will be write to external files when the function F1's fcinfo->flinfo->fn_mcxt is released; I also have a function F2 which depends on those external files, so when it runs, I want to make sure that all existing function F1's buffer (in this trasaction) have already write out to the external files. The two functions are independent, except when they are performed together.
As the result, I want that buffer to be a global variable in this transaction, so F2 can check it and decide if it is empty. If it is not empty, F2 can write it out manually.
Since PostgreSQL uses multiprocessing, one backend cannot see the global variables in another backend. You could write a _PG_init function that creates a shared memory segment for that purpose (see pg_stat_statements). That requires that your library is added to shared_preload_libraries.
A simpler alternative might be to use the LISTEN / NOTIFY facility of PostgreSQL to synchronize different backends.
I tried to use debug_access=all in vcs command line, but it seems I still can't dump the signals declared inside the task(). Is there any args I need to use?
AFAIK, tools do not yet allow you to dump variables with automatic lifetimes. This is because they come in and out of existence. Also, because of re-entrant behavior from threads or recursion, there might be multiple instances of the same named variable.
If these signals are inside a class method, you might be able to move them outside and make them class members. Otherwise you should be able to declare them as static variables as long as there is no re-entrant behavior.
dave_59 is correct, there's no way to do this. For tasks at least you can drive signals that are declared elsewhere inside the task. And you'll be able to monitor those signals. Functions I don't believe this is possible to modify external signals from inside a function. All inputs/outputs must be declared for a function.
I am going through the book by Galvin on OS . There is a section at the end of chapter 2 where the author writes about "adding a system call " to the kernel.
He describes how using asmlinkage we can create a file containing a function and make it qualify as a system call . But in the next part about how to call the system call he writes the following :
" Unfortunately, these are low-level operations that cannot be performed using C language statements and instead require assembly instructions. Fortunately, Linux provides macros for instantiating wrapper functions that contain the appropriate assembly instructions. For instance, the following C program uses the _syscallO() macro to invoke the newly defined system call:
Basically , I want to understand how syscall() function generally works . Now , what I understand by Macros is a system for text substitution .
(Please correct me If I am wrong)
How does a macro call an assembly language instruction ?
Is it so that syscallO() when compiled is translated into the address(op code) of the instruction to execute a trap ?(But this somehow doesn't fit with concept or definition of macros that I have )
What exactly are the wrapper functions that are contained inside and are they also written in assembly language ?
Suppose , I want to create a function of my own which performs the system call then what are the things that I need to do . Do , I need to compile it to generate the machine code for performing Trap instructions ?
Man, you have to pay $156 dollars to by the thing, then you actually have to read it. You could probably get an VMS Internals and Data Structures book for under $30.
That said, let me try to translate that gibberish into English.
System calls do not use the same kind of linkage (i.e. method of passing parameters and calling functions) that other functions use.
Rather than executing a call instruction of some kind, to execute a system service, you trigger an exception (which in Intel is bizarrely called an interrupt).
The CPU expects the operating system to create a DISPATCH TABLE and store its location and size in a special hardware register(s). The dispatch table is an array of pointers to handlers for exceptions and interrupts.
Exceptions and interrupts have numbers so, when exception or interrupt number #1 occurs, the CPU invokes the 2d exception handler (not #0, but #1) in the dispatch table in kernel mode.
What exactly are the wrapper functions that are contained inside and are they also written in assembly language ?
The operating system devotes usually one (but sometimes more) exceptions to system services. You need to do some thing like this in assembly language to invoke a system service:
INT $80 ; Explicitly trigger exception 80h
Because you have to execute a specific instruction, this has to be one in assembly language. Maybe your C compiler can do assembly language in line to call system service like that. But even if it could, it would be a royal PITA to have to do it each time you wanted to call a system service.
Plus I have not filled in all the details here (only the actual call to the system service). Normally, when you call functions in C (or whatever), the arguments are pushed on the program stack. Because the stack usually changes when you enter kernel mode, arguments to system calls need to be stored in registers.
PLUS you need to identify what system service you want to execute. Usually, system services have numbers. The number of the system service is loaded into the first register (e.g., R0 or AX).
The full process when you need to invoke a system service is:
Save the registers you are going to overwrite on the stack.
Load the arguments you want to pass to the system service into hardware registers.
Load the number of the system service into the lowest register.
Trigger the exception to enter kernel mode.
Unload the arguments returned by the system service from registers
Possibly do some error checking
Restore the registers you saved before.
Instead of doing this each time you call a system service, operating systems provide wrapper functions for high level languages to use. You call the wrapper as you would normally call a function. The wrapper (in assembly language) does the steps above for you.
Because these wrappers are pretty much the same (usually the only difference is the result of different numbers of arguments), wrappers can be created using macros. Some assemblers have powerful macro facilities that allow a single macro to define all wrappers, even with different numbers of arguments.
Linux provides multiple _syscall C macros that create wrappers. There is one for each number of arguments. Note that these macros are just for operating system developers. Once the wrapper is there, everyone can use it.
How does a macro call an assembly language instruction ?
These _syscall macros have to generate in line assembly code.
Finally, note that these wrappers do not define the actual system service. That has to be set up in the dispatch table and the system service exception handler.
I have following questions:
How is global code executed and global variables initialized in perl?
If I write use package_name; in multiple packages, does the global code execute each time?
Are global variables defined this way thread safe?
Perl makes a complete copy of all code and variables for each thread. Communication between threads is via specially marked shared variables (which in fact are not shared - there is still a copy in each thread, but all the copies get updated). This is a significantly different threading model than many other languages have, so the thread-safety concerns are different - mostly centering around what happens when objects are copied to make a new thread and those objects have some form of resource to something outside the program (e.g. a database connection).
Your question about use isn't really related to threads, as far as I can tell? use does several things; one is loading the specified module and running any top-level code in it; this happens only once per module, not once per use statement.
How global variables are set for drools stateless session.
Lets say two threads access same session but sets a global variable customer arraylist with
new arraylist for each thread. Does second thread's arraylist replaces first thread's arraylist for global variable customer.
That seems the case from StatelessKnowledgeSession class documentation :
StatelessKnowledgeSessions support globals, scoped in a number of ways. I'll cover the non-command way first, as commands are scoped to a specific execution call. Globals can be resolved in three ways. The StatelessKnowledgeSession supports getGlobals(), which returns a Globals instance. These globals are shared for ALL execution calls, so be especially careful of mutable globals in these cases - as often execution calls can be executing simultaneously in different threads. Globals also supports a delegate, which adds a second way of resolving globals. Calling of setGlobal(String, Object) will actually be set on an internal Collection, identifiers in this internal Collection will have priority over supplied delegate, if one is added. If an identifier cannot be found in the internal Collection, it will then check the delegate Globals, if one has been set.
http://docs.jboss.org/jbpm/v5.1/javadocs/org/drools/runtime/StatelessKnowledgeSession.html
Am i right?
Although I cannot give you a fully reliable answer (because I haven't tested this), I would say that you are right because
under the StatelessKnowledgeSession's hood, Drools uses a StatefulKnowledgeSession and in a stateful session, I would expect that the call of setGlobal(...) overrides the value from a previous call.
Globals are held in a "globals store"; this globals store is session-specific, which means that if you achieve to simultaneously access the same session using different threads, one thread will override the globals store of the other - whichever thread's setGlobal(...) is executed last.
I can confirm- globals are stored in shared memory between threads.
We were using a global to store the result from each execution and found that when multiple threads were executing at the same time, we would occasionally get the wrong result because another thread jumped in and overwrote the global before the previous thread had retrieved the value.