as most C programmers know libc gives a non portable functions for thread cpu affinity tuning (pthread_attr_setaffinity_np()). However, what I do not really know is how can this be done when implementing a kernel module. Any answer that mentions or redirects to some real examples would be rather helpful.
You should use kthreads, which stands for kernel threads. To create such on specified cpu, you should invoke kthread_create_on_cpu(). It is defined in include/linux/kthread.h. Thread will be created in sleep state, so you should call wake_up_process() on it. That's all.
You can get one example of using kthreads in my answer in this question.
You can use kthread_bind() function.
Related
To get perf statistics of parallel running threads -
To get list of threads I use thread list in /proc/self/task
Now I want to get ID of a thread's CPU time clock. But clock_getcpuclockid only works with PIDs.
pthread_getcpuclockid requires the pthread id of thread and I did not find any way to get pthread id from TId of thread so I am looking for any alternative solution to this problem. CLOCK_THREAD_CPUTIME_ID will return information of current only and I need information of all parallel threads. Any suggestions are welcome.
Is there any alternative to pthread_getcpuclockid? I wonder what pthread implementation does inside ?
Read time(7) & clock_gettime(2). You probably want to use CLOCK_THREAD_CPUTIME_ID
See also proc(5)
Is there any alternative to pthread_getcpuclockid? I wonder what pthread implementation does inside ?
This is simple, and implementation specific (probably varies between GNU libc & musl-libc). Most (AFAIK, all) C standard libraries on Linux are free software, so you can study their source code.
For musl-libc src/threads/pthread_getcpuclockid.c is fetching the clock id from the data related to the thread_t
For GNU libc, I leave the diving into its source code to you.
i am interested in the C programming, lately. I like how you only have a 'minimal' set of functions and datatypes (the C standard library) and still you can create almost everything with it.
But now to my question:
How do you make simple event-handling in C? I have read about the signals.h header and this would be what i am looking for... if there were signals exclusivly reserved for the user. But i can never be sure that the environment unexpectedly raises one of the signals that i can use with the C standard library.
Okay... there is the extended signals header in linux/unix with 2(?) signals for the user... but i can imagine situations where you need more...
Besides i want to learn writing C platform independent. I heard about "emulating signals" by listening to a socket... but that would also not be platform independent.
Is there any way to write a C program that has to handle events without getting platform dependent only by help of the standard C library?
Thank you for any hints;
Yeap, that is exactly what Unix designed for, 2 user signals. Supposedly it all depends on what you use signal for. If you are just to relaying some events asynchronously, use sockets will do. Look up for event-loop. You can even create unlimited complexity behind that. Signals are a very special group of functions for OS specific reasons, such as somebody is trying to kill you. In that respect, the options should be limited in order to trim down overhead for OS operations.
My suggestion is to stay away from signals, unless you know very specifically what you are using it for. Signal is used for OS to communicate with you, not for you to communicate with yourself, although from many different places. And there are only defined reasons why OS want to give you a call. Hence, I tend to think the original 2 user defined signals are more than enough.
Unfortunately I think you are going to run into platform dependencies here. You can write a multithreaded application, where one thread waits for some input and then sends a message / makes a call when that input has arrived (such as waiting for an input string on a console). But that is not baked into C99, and you would have to rely on platform dependent third party libraries. Here is a useful post on that subject. I know this isn't the answer you want, but I hope it helps.
C: Multithreading
edit: C11 supports multithreading natively, see
http://en.cppreference.com/w/c/header
I haven't used this yet.
I wanted to know how to implement my own threading library.
What I have is a CPU (PowerPC architecture) and the C Standard Library.
Is there an open source light-weight implementation I can look at?
At its very simplest a thread will need:
Some memory for stack space
Somewhere to store its context (ie. register contents, program counter, stack pointer, etc.)
On top of that you will need to implement a simple "kernel" that will be responsible for the thread switching. And if you're trying to implement pre-emptive threading then you'll also need a periodic source of interrupts. eg. a timer. In this case you can execute your thread switching code in the timer interrupt.
Take a look at the setjmp()/longjmp() routines, and the corresponding jmp_buf structure. This will give you easy access to the stack pointer so that you can assign your own stack space, and will give you a simple way of capturing all of the register contents to provide your thread's context.
Typically the longjmp() function is a wrapper for a return from interrupt instruction, which fits very nicely with having thread scheduling functionality in the timer interrupt. You will need to check the implementation of longjmp() and jmp_buf for your platform though.
Try looking for thread implementations on smaller microprocessors, which typically don't have OS's. eg. Atmel AVR, or Microchip PIC.
For example : discussion on AVRFreaks
For a decent thread library you need:
atomic operations to avoid races (to implement e.g a mutex)
some OS support to do the scheduling and to avoid busy waiting
some OS support to implement context switching
All three leave the scope of what C99 offers you. Atomic operations are introduced in C11, up to now C11 implementations don't seem to be ready, so these are usually implemented in assembler. For the later two, you'd have to rely on your OS.
Maybe you could look at C++ which has threading support. I'd start by picking some of their most useful primitives (for example futures), see how they work, and do a simple implementation.
Is the Linux kernel aware of pthreads in the user address space ( which i dont think it is..but i did not find any info abt that). How does the Instruction pointer change when thread switching takes place.. ??
The native NPTL (native posix thread library) used in Linux maps pthreads to "processes that share resources and therefore look like threads" in the kernel. In this way, the kernel's scheduler directly controls the scheduling of pthreads.
A "pthread switch" is done by the exact same code (in the kernel) that handles process switches. Simplified, this would be something like "store previous process state; if the next process uses a different virtual address space then switch virtual address spaces; load next process state;" (where "process state" includes the instruction pointer for the process/thread).
Well the Linux kernel doesn't know about user threads (pthread does in userspace, moreover the kernel doesn't really care about them except it just needs to know what to schedule).
The instruction pointer is changed in the kernel during what's called a context switch. During this switch the kernel essentially asks the scheduler what's next? the scheduler will hand it a task_struct which contains all the information about the thread and the interrupt handler for a context switch will go ahead and set the values on the CPU accordingly (page tables, instruction pointer, etc...) and when that code is done the CPU simply just starts executing from there.
1) The kernel doesn't know about user-level threads. However, NPTL isn't user level
2) This is a really broad question. You should look at an OS book. It will go into depth on that issue and all other involved in a context switch.
Can you create a "conversation" (or-Information Exchange) between 2 threads, if those two threads are calling a shared DLL library? And, if this conversation is possible, What are the requirements or restrictions for it to actually take place between the threads?
This question was given to us by our professor. I can only assume, by the question's context, that my professor is referring to synchronization required between the two threads for the conversation to succeed, or restricting the DLL linking type (Implicit or Explicit).
Then again, assumptions or not, I am rather at a loss here :)
P.s. - In this case, we are programming in C.
Thanks in advance for your help :)
It appears that your professor is testing your understanding of what space DLLs are loaded into, and how this relates to threads.
Without doing your homework for you, I encourage you to consider what happens if two threads each call LoadLibrary() on a particular DLL. Is the DLL loaded into the process twice?
Given the result of the above, what implications does this have regarding the two threads making calls into that DLL?
Did you think about using Boost.Interprocess, because C++ has many implicit allocations. In general you need a system-wide mutex in order to synchronize access to that portion of memory.
I think that give each thread calls for LoadLibrary() the system will allocate different memory segment for each DLL thus each thread will not have a mutual resource to work with thus they will be unable to exchange any information.
but...
Say we will link explicitly to the DLL using #Pragam Comment(lib, "myDLL.lib")
I think that in this way you'll be able to share resources between threads because the DLL is fully loaded at the program startup.
Jeff? .. is this right ?...