[ale] Help with C project

Christopher Hagler haglerchristopher at gmail.com
Sat Jan 23 14:41:36 EST 2016


Thank you for the reply. When I create a process, I give each thread their
own condition variable because I can control which threads are run. I have
a function called process_create that in turn calls pthread_cond_init. From
my understanding a call to pthread_cond_signal does not guarantee
scheduling order. Threads are not scheduled in the order they call
pthread_cond_wait. This is why I give each thread their own condition
variable. The scheduler will call process_start that will call
pthread_cond_signal on the process struct passed in as a parameter. All of
that works correctly. However a call to process_stop which calls
pthread_cond_wait does not seem to work. From what I have read, it all
seems correct, but the threads continue to run.
On Jan 23, 2016 12:40 PM, "Pete Hardie" <pete.hardie at gmail.com> wrote:

> It's been a while since I use pthreads directly, but the modus operandi of
> condition variables is that you declare one before the
> threads that use it are started, and the threads that you want to wait
> will call wait() to pause until the another thread signals a change,
> and then you would check the condition variable value to see if it is the
> desired value to proceed.
>
> On Sat, Jan 23, 2016 at 11:52 AM, Christopher Hagler <
> haglerchristopher at gmail.com> wrote:
>
>> I am working on a home automation project written in C. It allows a user
>> to automate daily task with open source hardware and software. However,
>> since I am lacking experience with pthreads, I have run into a couple of
>> issues that I cant seem to resolve. The intentions of the code where the
>> issues reside are:
>>
>> The project allows drivers to be written as shared objects that, which in
>> turn, will control a remote hardware device or devices with all
>> communication happening through shared memory. The Scheduler module will
>> take the shared object, and schedule it to run via process queues. Once the
>> process, a struct containing the shared object and an abstraction for a
>> pthread, runs for its time slot, the scheduler will stop the process and
>> place it in another process queue. The whole idea was to simulate an
>> operating system scheduler because potentially there could be a few hundred
>> threads. This is where the first issue resides. I am having trouble putting
>> the process to sleep. I have done some research on pthreads and supposedly
>> this can be accomplished via pthread condition variables. This is the
>> solution I have attempted, and apparently I have not implemented it
>> correctly. It will start the process which will run, but when I try to put
>> it to sleep, it keeps running.
>>
>> The second issue is when ever you run the program, it fails to link the
>> shared object sometimes. However, if you have to quickly run the program
>> back-to-back, it will start and run fine. I am not sure why this is
>> happening. It could possibly be linked to my setup, but I am not sure. I am
>> running Opensuse in Virtual Box.
>>
>> Any advice on these issues would be greatly appreciated. I also know
>> there are a couple of people who have been wanting to learn C, and you are
>> more than welcome to join the project if you want.
>>
>> The code base:
>> https://github.com/haglerchristopher/automation/tree/development
>>
>> Thanks for the help.
>>
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>>
>
>
> --
> Pete Hardie
> --------
> Better Living Through Bitmaps
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20160123/6b21b61d/attachment.html>


More information about the Ale mailing list