vxWorks pthreads - pthreads

All the documentation I've read so far seems to indicate that posix thread support exists in my version of vxWorks (6.8) however a simple test application fails to perform as expected. Here's the source:
tTest.h
#include <pthread.h>
class tTest
{
public:
tTest();
virtual ~tTest();
private:
pthread_t tid;
static void* Worker(void* args);
};
tTest.cpp
#include <stdio.h>
#include "tTest.h"
tTest::tTest()
{
printf("Starting up...\n");
if(pthread_create(&tid, NULL, &tTest::Worker, NULL))
{
printf("Failed to create thread.\n");
}
}
tTest::~tTest()
{
if(pthread_join(tid,NULL))
{
printf("Failed to join thread.\n");
}
printf("Shutting down...\n");
}
void* tTest::Worker(void* args)
{
printf("ThreadID: %d\n", (int)pthread_self());
return NULL;
}
The entrypoint for the vxWorks kernel module is simply:
#include "tTest.h"
int tTest_main()
{
tTest m;
return 0;
}
The startup/shutdown messages are good, but the worker thread is not. This works fine and as expected in linux. What am I missing?

Assuming you are using the WindRiver Workbench to develop this application, you will need to use the kernel configuration and enable the POSIX threads package.
This can be done by performing a search on the kernel configuration for 'pthreads'

POSIX support exists in VxWorks 6.8, but most POSIX components are not included in the default configuration. In workbench POSIX support is enabled under the POSIX Components folder of the kernel configuration.
POSIX support is broken up into a number of different modules, e.g. process scheduling, clocks (included by default), message queues, etc.
If you are developing under workbench, including the appropriate component (in this case INCLUDE_POSIX_THREADS) will also include any other components which pthreads depend on. If you are configuring a kernel outside of workbench, you will need to ensure you include all dependencies manually.

Related

About program export variables

The graphics card manufacturer has an optimization scheme. The following variables are exported from the program, and the program will be executed with an independent graphics card. For the program compiled by the new version of the bcc compiler, the exported variables are prefixed with an underscore, and the -vu parameter is not supported. I don't know how to solve this.
// http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/OptimusRenderingPolicies.pdf
// The following line is to favor the high performance NVIDIA GPU if there are multiple GPUs
// Has to be .exe module to be correctly detected.
extern "C" __declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001;
// And the AMD equivalent
// Also has to be .exe module to be correctly detected.
extern "C" __declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 0x00000001;
bcc32 old version
bcc32c new version

How does erlang implements preemptive scheduling with one OS thread?

I want to know how erlang's VM preempts the running code and contexts the stack. How it can be done in a language such as c?
The trick is that the Erlang runtime has control over the VM, so it can - entirely in userspace - keep track of how many VM instructions it's already executed (or, better yet, an estimate or representation of the actual physical computation required for those instructions - a.k.a. "reductions" in Erlang VM parlance) and - if that number exceeds some threshold - immediately swap around process pointers/structs/whatever and resume the execution loop.
Think of it something like this (in kind of a pseudo-C that may or may not actually be C, but I wouldn't know because I ain't a C programmer, but you asked how you'd go about it in C so I'll try my darndest):
void proc_execute(Proc* proc)
{
/* I don't recall if Erlang's VM supports different
reduction limits for different processes, but if it
did, it'd be a rather intuitive way to define process
priorities, i.e. making sure higher-priority processes
get more reductions to spend */
int rds = proc->max_reductions;
for (; rds > 0; rds--) {
/* Different virtual instructions might execute different numbers of
physical instructions, so vm_execute_next_instruction will return
however many reductions are left after executing that virtual
instruction. */
rds = vm_execute_next_instruction(proc, rds);
if (proc->exited) break;
}
}
void vm_loop(Scheduler* sched)
{
Proc *proc;
for (;;) {
proc = sched_next_in_queue(sched);
/* we'll assume that the proc will be null if the
scheduler doesn't have any processes left in its
list */
if (!proc) break;
proc_execute(proc);
}
}
Proc* sched_next_in_queue(Scheduler* sched)
{
if (!sched->current_proc->exited) {
/* If the process hasn't exited yet, readd it to the
end of the queue so we can resume running it
later */
shift(sched->queue, sched->current_proc);
}
sched->current_proc = pop(sched->queue);
return sched->current_proc;
}
This is obviously quite simplified (notably excluding/eliding a lot of important stuff like how VM instructions are implemented and how messages get passed), but hopefully it illustrates how (if I'm understanding right, at least) Erlang's preemptive scheduler and process model works on a basic level.
All code of Erlang will compile to operation code of Erlang's VM. Erlang's VM execute Erlang's operation code by OS's threads which are created at startup of Erlang's VM.
Erlang's code run on Virtual CPUs which are controlled by Erlang's VM. And Erlang's VM consider IO as interrupt of Virtual CPUs. So Erlang's VM implements a machine and a scheduler like an OS. Because of operation code and non-blocking IO, we can implements preempts in Erlang's VM using C languange.

Syntax/Functions used in the OpenCL-Implemantation of OpenCV

I try to understand the use of OpenCL within OpenCV but I don´t get it:
This is an example Codepart from orb.cpp where a Kernel with the name ORB_HarrisResponses located in orb.cl is created (propably):
ocl::Kernel hr_ker("ORB_HarrisResponses", ocl::features2d::orb_oclsrc,
format("-D ORB_RESPONSES -D blockSize=%d -D scale_sq_sq=%.12ef -
D HARRIS_K=%.12ff", blockSize, scale_sq_sq, harris_k));
return hr_ker.args(ocl::KernelArg::ReadOnlyNoSize(imgbuf),
ocl::KernelArg::PtrReadOnly(layerinfo),
ocl::KernelArg::PtrReadOnly(keypoints),
ocl::KernelArg::PtrWriteOnly(responses),
nkeypoints).run(1, globalSize, 0, true);
But this isn't the regular OpenCL-Syntax (functions like clCreateKernel ...). Does someone know where I can get a basic understanding of the OpenCV`s OpenCL implementations to answer questions like:
Where is the connection between the "normal" OpenCL and the OpenCV OpenCL?
Where the program is built from the kernel source files?
Where is the function, which creates the kernel explained?
etc
I couldn´t find a document or related questions on the web.
Thanks
Edit: Thanks for answering it helped to understand a few things:
ocl::Kernel hr_ker("ORB_HarrisResponses", ocl::features2d::orb_oclsrc,
format("-D ORB_RESPONSES -D blockSize=%d -D scale_sq_sq=%.12ef -D HARRIS_K=%.12ff", blockSize, scale_sq_sq, harris_k));
In this part the kernel code ORB_HarrisResponses located in orb.cl build within the string ocl::features2d::orb_oclsrc is created as hr_ker (right?).
But what does the format(...) thing do?
if hr_ker.empty() return false;
return hr_ker.args(ocl::KernelArg::ReadOnlyNoSize(imgbuf),
ocl::KernelArg::PtrReadOnly(layerinfo),
ocl::KernelArg::PtrReadOnly(keypoints),
ocl::KernelArg::PtrWriteOnly(responses),
nkeypoints).run(1, globalSize, 0, true);
In this part of the Kernel arguments imgbuf, layerinfo, keypoints are set and output of the kernel is stored in responses.
What is going on with nkeypoints?
Why no ocl::KernelArg infront of this parameter?
The kernel in orb.cl has 7 arguments but only 5 are set, why?
What exactly is returned from return hr_ker.args(...)?
This syntax is kind of internal OpenCV "sugar" to not repeat some common code blocks. Unfortunately there is no good documentation so the only way to learn it is looking through source code and examples.
Some tips for you:
Connection between OpenCL API and opencv are in modules\core\src\ocl.cpp (see Kernel, Kernel::Impl, Program, ProgramSource, KernelArg classes).
Source code of kernels stored in *.cl files (for example ORB kernels are in modules\features2d\src\opencl\orb.cl file). On module building code of kernels are copying to auto-generated cpp file (for example opencl_kernels_features2d.cpp) and code can be accessed by ocl::features2d::orb_oclsrc.
To use opencl implementation in opencv you need to pass to function cv::UMat instead of regular cv::Mat (see CV_OCL_RUN_ macro and cv::OutputArray::isUMat() method).
Basically all opencl implementation inside opencv does the following:
Defines kernel parameters, like global size, block size, etc.
Creates cv::ocl::Kernel using string with source code and defined parameters. (If kernel is not created or there is no opencl implementation for specified input parameters processing is passed to regular cpu code).
Pass kernel arguments via cv::ocl::KernelArgs. There is several types of parameters to optimize processing: read-only, write-only, constant, etc.
Run kernel.
So for end user using opencl implementation is transparent. If something goes wrong processing is switched to cpu implementation.
Let's discuss following code snippet:
return hr_ker.args(ocl::KernelArg::ReadOnlyNoSize(imgbuf),
ocl::KernelArg::PtrReadOnly(layerinfo),
ocl::KernelArg::PtrReadOnly(keypoints),
ocl::KernelArg::PtrWriteOnly(responses),
nkeypoints).run(1, globalSize, 0, true);
and ocl function declaration:
ORB_HarrisResponses(__global const uchar* imgbuf, int imgstep, int imgoffset0,
__global const int* layerinfo, __global const int* keypoints,
__global float* responses, int nkeypoints )
nkeypoints is integer, so no need to wrap it to ocl::KernelArg. It will be passed directly to kernel.
ocl::KernelArg::ReadOnlyNoSize actually expands to three parameters: imgbuf, imgstep, imgoffset0.
Other kernel arguments doesn't expand, so it represent single parameter.
hr_ker.args returns reference to cv::ocl::Kernel so you may use following construction: kernel.args(...).run(...).
Some useful links:
cv::format documentation. It works like boost::format.
Hope it will help.

What isthe best way to replay a "session"

In a first phase, i collect a list of constraints. Then, i would like to store this "session", i.e. All the constraints but all the associated variables as well in a file so that I can, in a second phase, read back the constraints and assert them, or even negate some of them before asserting.
What is the best way (fast and reliable) to store such a "session" in a file, and read it back ? Would the Z3_parse_smtlib2_file() API be the right way ? I have tried the Z3_open_log() API, but I don't find the API to read the log file generated by Z3_open_log(). And what about z3_log_replay(). This API does not seem to be exposed yet.
Thanks in advance.
AG
The log file created by Z3_open_log() can be replayed with Z3.exe (stand alone interpreter, not the lib) through the command line option /log myfile. As of today, I haven't seen any API in Z3 library that allows such a replay. For the time being, I have understood that the replay is deemed for debug analysis.
However, you can hack the library (just expose the z3_replayer class in z3_replayer.h) and use it to replay any log file, it is quite easy. The source code of my little feasibility-proof is given below, and is working fine as far as I know. I think it is very nice to be able to do that because sometimes I need to replay a session for debugging purpose. It is good to be able to replay it from a file, rather than from my whole program which is a bit heavy.
Any feedback would be very welcome. Also I would be interested to know whether this functionality could be integrated in the lib, or not.
AG.
#include <fstream>
#include <iostream>
#include "api/z3_replayer.h"
int main(int argc, char * argv[])
{
const char * filename = argv[1];
std::ifstream in(filename);
if (in.bad() || in.fail()) {
std::cerr << "Error: failed to open file: " << filename << "\n";
exit(EXIT_FAILURE);
}
z3_replayer r(in);
r.parse();
Z3_context ctx = reinterpret_cast<Z3_context>(r.get_obj(0));
check(ctx,Z3_L_TRUE); // this function is taken from the c examples
return 0;
}

Obtain LWP id from a pthread_t on Solaris to use with processor_bind

On Solaris, processor_bind is used to set affinity for threads. You need to know the LWPID of the target thread or use the constant P_MYID to refer to yourself.
I have a function that looks like this:
void set_affinity(pthread_t thr, int cpu_number)
{
id_t lwpid = what_do_I_call_here(thr);
processor_bind(P_LWPID, lwpid, cpu_number, NULL);
}
In reality my function has a bunch of cross platform stuff in it that I've elided for clarity.
The key point is that I'd like to set the affinity of an arbitrary pthread_t so I can't use P_MYID.
How can I achieve this using processor_bind or an alternative interface?
Following up on this, and due to my confusion:
The lwpid is what is created by
pthread_create( &lwpid, NULL, some_func, NULL);
Thread data is available externally to a process that is not the one making the pthread_create() call - via the /proc interface
/proc/<pid>/lwp/<lwpid>/ lwpid == 1 is the main thread, 2 .. n are the lwpid in the above example.
But this tells you almost nothing about which thread you are dealing with, except that it is the lwpid in the example above.
/proc/pid/lwp/lwpid/lwpsinfo
can be read into a struct lwpsinfo which has some more information, from which you might be able to ascertain if you are looking at the thread you want. see /usr/include/sys/procfs.h
Or man -s 4 proc
The Solaris 11 kernel has critical threads optimization. You setup which threads require special care, the kernel does the rest. This appears to be what you want. Please read this short explanation to see if I understood what you want.
https://blogs.oracle.com/observatory/entry/critical_threads_optimization
The above is an alternate. It may not fly at all for you. But is the preferred mechanism, per Oracle.
For Solaris 10, use the pthread_t tid of the LWP with an idtype_t of P_LWPID in your call to processor_bind. This works in Solaris 8 -> 11. It works ONLY for LWP's in the process. It is not clear to me if that is your model.
HTH

Resources